關於 AuthContext 在登入時會將舊 token 初始為 undefined 問題

[ttpss930141011]

前言

Branch

這次的 branch：
https://github.com/Game-as-a-Service/Game-Lobby-Web/tree/fix/justin-test

情況

搭好，前幾日在 Discord 出現了 token === undefined 的 issue，但在我印象中在登入後 token 就會先被設定一個值，沒道理在 useRequest 時 token 又等於undefined，研究了一下之後發現 AuthContext 在拿到一個預設 token 之後，被設定成 undefined (但並沒有程式碼去setToken(undefined)

Root cause

原先帶有舊 token 的 AuthContext，在 Startup 組件在打出 authenticate request 前被設定成 undefined，導致有此次 issue。

我的猜想

我猜想 AuthContext 被重新初始化了，但我不太清楚為什麼 useContext 會在這個奇怪的時間點進行重新初始化，問了 GPT 後他給我了這個答案：

正常的 React 應用程式中，頁面重新渲染並不會導致 AuthProvider 中的狀態（token 和 currentUser）丟失。但在頁面刷新後，應用程式的所有狀態都會被重置，需要特別處理來保留用戶的登入狀態。

但是在登入跳轉時應該不會導致 token 丟失，讓我很困惑 useContext 重置的機制，所以特地向各位尋求幫助，但整個問題的前後文很冗長，我嘗試優化了一下內容，希望這樣更清楚明瞭，並請各位大大不吝賜教。

登入流程

由於登入流程比較複雜，大致交代流程：

Development

1. pages\login.tsx line: 58 登入按鈕起蕊
2. 同一檔案31行 onLoginClick function 執行，因為 isMock === true，所以他會執行 getLoginEndpoint 並防止事件冒泡到 button href
3. request 打到 pages\api\mock\login.ts 並回傳 mock_loginEndpoint (/auth/login)，接著 redirect to mock_loginEndpoint 也就是 /auth/login
4. pages\auth\login.tsx 內去 getMockToken 打API取得了 "login-token" 這個 token
5. 同一檔案16行 push 到 "/auth/token/login-token"，pages\auth\token\[token].tsx setToken(token) 之後跳轉到主頁
6. containers\util\Startup.tsx line: 25 發起 request 時 useRequest 裡的 token 卻變成 undefined，而且用 useEffect 去追蹤 token 也發現他在送 request 之前變成 undefined，如紅問號處。
7. 但因為 Development 環境並沒有擋 Bearer token 所以就正常打了 mock authenticate API 之後重新拿到了新的 token，沒毛病。
   

Production

1. pages\login.tsx line: 58 登入按鈕起蕊
2. 因為 isMock === false 所以他會 GET / https://api.gaas.waterballsa.tw/login?type=google-oauth2 並讓 server 轉到 Google 那
3. Google 登入完 302 redirect 到 https://lobby.gaas.waterballsa.tw/auth/token/${token}
4. 如同 Development 第五步，pages\auth\token\[token].tsx setToken(token) 之後跳轉到主頁
5. 然後遇到同一個問題，才剛拿到的熱騰騰 token 在 useRequest 時變成 undefined，差別是這次後端 POST / authenticate 實作成 protected API 導致 401，無法像在 Development 環境時拿到新 token。

Zustand 替換 useContext

在 fix/justin-test 這個 branch 中，我有用一個輕量 state management tool Zustand 去做原先 AuthContext 在做的事情，並把他持久化在 sessionStorage 裡面，解決了上述的 token 變 undefined 的問題：

有興趣的話可以在 hooks\context\useAuth.ts 中將 useContext 替換成註解起來的 useAuthStore 看看效果

想討論的議題

• 為什麼 AuthContext 的 token 會在 authenticate request 中變回 undefined？
• 此專案有沒有意願加入 state management tool？

Note: 我先前有實作了 Zustand 整合 Socket.io 的小 demo，用起來差不多像是這樣子：frontend/src/store/socket.ts

[IamSaker]

Hi @ttpss930141011,

謝謝你 trace 了整段 refresh token 流程，但我沒有看到造成 root cause（token 是 undefined）的原因。
因此，我會有兩個建議：

1. 找出 token 會是 undefined 的 root cause 且 hotfix
2. 跟團隊成員討論是否引入新的 state management tool

延伸議題：如果要防止下一次遇到 token 是 undefined，是不是要寫測試來保證此段邏輯功能正確性？

[ttpss930141011]

謝謝 Saker 這邊的回覆，我有稍作修改內容，希望能更清楚的表達我的問題。
這次 issue 已經因為 authtenticate 待釐清被 hotfix 了，但我還是很好奇 React useContext 重置的機制，期待其他人的回覆

[Yuwen-ctw]

Hello 各位，
有關 authentication 這支 API 會夾帶 undefined token 的議題，以下提供個人想法：
個人會嘗試追蹤的方向有兩個，一個是為何該 API 會在沒有 token 的情況下發出請求，第二個則是為何在該時機點 authContext 裡的 token 會是 undefined。

先整理幾個背景狀況提前說明:

1. 所有 API 中，只有兩隻不會在 Request Header 裡放置 token，第一個是點擊第三方登入按鈕所觸發的 login API；另一個是前端在開發模式使用的 getMockToken API，因此 authentication 這隻 API 被預期是要帶 token 的。
2. 所有須帶 token 的 API，其 token 值均來自 authContext 中以 useState 進行管理的狀態 「token」，並且有三種可能性: undefined (預設值), null (被登出), "token"(實際存在過的 token)。
3. token 狀態更新的時機點包含:
   　(1) 從第三方登入點擊登入並成功取得 token 後，由 [token] 頁面元件執行更新。 (token)
   　(2) authentication API 成功回傳新 token 時 (token)
   　(3) 任一 API 回傳代碼 401 後 (null)
   　(4) 點擊登出按鈕後 (null)
   　(5) 首次進入 Startup.tsx，並從 cookie 取不到 token 時 (null)
4. 針對 3-(5) 的 cookie 機制，是前端現行用來持久化保存 token 的方法，此機制的其中一種作用，在於可保持使用者的登入狀態，即使後續使用者關閉網頁，或進行重新整理，依然可以保留先前儲存的 token ，並依此 token 呼叫 authentication API 向後端進行驗證。
5. 呼叫 authentication API 的程式碼是在 Startup.tsx，Startup.tsx 是一層 HOC，在真正渲染給使用者看的元件 (畫面) 之前，先包一層無 UI 性質的功能性元件，而目前此功能性元件的用途是做身分驗證，並取得 currentUser 的資訊，當前述兩步驟完成後，才開始渲染當前路由真正的元件；此 HOC 同時也負責監聽 authContext 的 token 狀態，若發現 token 為 null，則重置 currentUser 以及 cookie 內 token 的資料，並將使用者導至登入頁（上述第 3-(3) ~ 3-(5) 點的後續）。

一、為何該 API 會在沒有 token 的情況下發出請求

觀察目前 Startup.tsx authentication API 被呼叫的程式碼，節錄如下：

// Startup.tsx
  const { token, setToken ... } = useAuth();
  const { authentication, getTokenInCookie ,... } = useUser();
  useEffect(() => {
    async function fetch() {
      const jwt = getTokenInCookie();
      if (jwt) {
        const res = await authentication(jwt);
        if (res.token) {
          setToken(res.token);
        }
      } else {
        setToken(null);
      }
    }

    fetch();
  }, []);

可以發現是透過 useEffect 呼叫 fetch 函式，該函式先嘗試透過 cookie 取得 jwtToken，若有成功取得，則執行 API，並將回傳結果賦值給 authContext 的 token，倘若失敗則將 token 設為 null。

此處個人的看法是，cookie 中有留存 jwtToken 並不代表 authContext 裡的 token 也一定有值，回顧背景狀況第 2 點，API 夾帶的 token 只會從 authContext 取得，因此這裡尚未針對 「cookie 有存 jwtToken 但 authContext 的 token 不存在」的情境進行例外處理，是造成此 API 帶到 undefined 的第一層原因。

然於背景狀況第 3 點有說明，除執行 authentication API 之外，還有登入這個時機點可以更新 authContext 的 token，邏輯上從登入頁登入後，在 [token] 路由的元件使用 setToken 賦值，再經由 Startup.tsx HOC 確認身分，並取得登入者資料，應該是一氣呵成沒有意外才對；而上週發生異常的情境，正是使用者走了登入流程，卻依然夾帶了 undefined 的 token，這個部分是屬於另一個我也尚未釐清的議題，稍待討論。

先接續背景狀況第 4 點，本專案有實作讓使用者即使離開網站依然可以保留離開前的 token 的機制，因此造訪網站的使用者不一定會走登入流程來驗證身分並更新 authContext 的 token。
我們預期若使用者沒有進行登出並關閉網站，下次再重新造訪時，會先經由 Startup.tsx HOC 進行身分驗證，若後端判定 token 有效，則換發新的 token ，前端接著會將新 token 賦值給 authContext ，其實也就是前面節錄的程式碼邏輯。

但是，相同的程式碼就會得到相同的結果，依照目前的解讀，在這種情形下，雖然 cookie 保留了 token，但此時 authContext 的 token 尚未有值 (undefined) ，因此請求 authentication API 時，依然會帶到 undefined 的 token，故個人認為解決 API 誤帶 undefined 的議題，可以先從這裡下手。
初步更改後程式碼如下：

// Startup.tsx
  const { token, setToken ... } = useAuth();
  const { authentication, getTokenInCookie ,... } = useUser();
  const [firstRender, setFirstRender] = useState(true);

  useEffect(() => {
    async function fetch() {
      const res = await authentication(token!);
      res.token && setToken(res.token);
    }
    if (firstRender) {
      setFirstRender(false);
      setToken(getTokenInCookie() || null);
    } else {
      token && fetch();
    }
  }, [firstRender]);

在 React 中，狀態的更新可能是非同步的 (參考官方範例)，在同一個函式使用 setToken，並不會立即讓下一行程式碼訪問到最新的 token ，因此上述程式碼異動的重點是，強制讓此 useEffect 至少執行兩次，第一次嘗試從 cookie 拿到 jwtToken，並使用 setToken 更新狀態，等到第二次進來時，就能保證 token 是更新過後的並依此 token 執行身分驗證，開發模式的結果截圖如下，可以觀察到這次 API 正確帶入了開發模式下模擬的 token: login-token ：

上述程式碼尚有未深入思考之處，譬如額外用了一組似乎可避免的狀態來控制流程，以及 useEffect 的依賴陣列沒有如實納入相關變數與函式等等，因此不適合納進主分支作為解決方案，但想說明的是 authentication API 誤帶 undefined token 的議題，是有可能透過調整 Startup.tsx 的邏輯來克服的。

二、為何在該時機點 authContext 裡的 token 會是 undefined

這個議題反覆測試了好幾次，目前沒有肯定的答案，只有一些線索可以分享：

1. authContext 裡的 token 為 undefined 非人為造成的，原因如背景說明第 2 點所述，只有初始建立狀態之時，才是 undefined，因此推測此 Context 是被重新 mounted 了，但是被重新 mounted 是甚麼造成的就還不確定了。
2. 不只 authContext 被重置，觀察到 axiosContext 也是從登入頁面進到 Startup.tsx 時，都會先回歸到初始值。
3. 亦不是只有登入頁到 Startup.tsx 這段會發生上述現象，從大廳進到房間，或從房間返回大廳，都必然發生；但唯一的例外是在大廳與房間列表之間切換（使用 Next/Link 元件 或用 useRouter hook 進行導頁似乎均有相同的結果）。

目前可能可以從兩個方向測試或釐清，第一是，是否有可能為 Next.js 的 prerender 機制的因素，裡面提到 「By default, Next.js pre-renders every page. This means that Next.js generates HTML for each page in advance, instead of having it all done by client-side JavaScript.」，第二是往前追朔以前的 commit，確認是否在專案之初，每次切換路由就會造成 context們重置。

最後 Justin 提到的 Zustand 狀態管理套件，我覺得可以考慮，原因是個人如果要改寫 Startup.tsx 的邏輯，會盡量思考資料在各時機點的狀態為何，來避免預料之外的情況，因此可能會把 useEffect 寫得很大，再加上有依賴陣列的關係，寫得不好或思考不全面有可能造成 API 重複多打數次的情形，嘗試寫了幾個版本都還不太滿意；而稍早使用 Justin 提供的分支測試 Zustand，發現沒有動邏輯亦可以解決此議題，同時也沒有比過去多打重複的 API ，真香。

以上說明，供參考，謝謝！