Twitter 專案問題解決與工具應用

在進行 Twitter 專案開發時，因為嘗試使用和教案不一樣的方式實作，所以在登入驗證這段稍微卡了關。

規格說明

• 在前後分離專案中，為後端 API 建立登入狀態/身分驗證機制。
• 前後端分屬不同網域。

PR 連結
頁面連結
我在實作中的角色: 專案初始建置(登入驗證機制、資料 models)、協作 API 路由及功能。

工具選擇

在之前的餐廳論壇實作中是使用 passport-local + passport-jwt 來進行登入驗證。觀察了之前的專案結構後發現， passport-local 對這次專案來說是非必要的。因為它是使用 cookie-session 機制進行，而 cookie 無法跨網域使用。

在這次的 Twitter 專案中，前後端分屬不同網域，所以 passport-local 的作用就只剩下「檢查帳號密碼是否正確」而已，實際上「是否擁有權限」這件事還是要在每條路由驗證使用者所攜帶的 token ，也就是由 passport-jwt 來處理。所以這次在建立登入機制時就打算完全捨棄 passport-local ，只使用 passport-jwt 來實作登入驗證。

發生問題與解決過程

問題發生原因

• 對驗證機制還不夠熟悉，導致實作時在多個地方發生邏輯錯誤
  因為對 passport 使用不夠熟悉，邏輯大多還是參考 passport-local 撰寫，忽略了「執行順序」造成的影響。
• 沒有完全依照自動化測試要求，造成無法通過
  自動化測試有針對模組引入方式、使用方式進行很明確的要求，因為沒有完全參照導致錯誤。

  // 通過
  const helpers = require('../_helpers')
  if (helpers.getUser(req) === 'admin') {...}
  
  // 不通過
  const { getUser } = require('../_helpers')
  if (getUser(req) === 'admin') {...}

設定停損機制/替代方案

雖然認為只使用 passport-jwt 這個方法是絕對可行的，但因為是有時限性的協作專案，為了不影響隊友開發，所以其實是有做出備用方案(餐廳論壇作法)再慢慢花時間研究並除錯。如果沒在預估時間裡完成，就可以直接切換驗證方式。

再次確認測試要求

重新檢視自動化測試內容，確認登入驗證是怎麼做處理的。包含 helper 的引入及使用方式，確認是否因做法不同造成測試不通過。

重新整理登入/驗證邏輯

• 登入 API 只負責檢查帳號密碼是否正確，正確則簽發 JWT token。
• 因為幾乎每條路由都需要驗證權限，所以 token 驗證放進 middleware 處理，驗證成功需用 next 進入下個執行流程。
• API 路由有限制 user/admin 權限，配合測試檔機制在 token 驗證成功後，將 user 資料塞進 request 裡。

查詢輔助資料

包含查閱官方文件、Stack Overflow、部落格文章、參考實作影片/專案…等。

再次開始實作

以上部分都有確實理解後，重新開始實作。過程中即時確認邏輯是否有誤、使用 console.log 檢查各個環節。重新開始後發現，之前因為 middleware 調用順序、將 user 資料塞進 request 裡的時機錯誤…等原因導致結果不如預期。

小結

這個實作嘗試真的很值得，讓自己在使用不熟悉的工具時能夠跳脫「照本宣科」的開發方式! 仔細思考為什麼這樣做? 兩種方式差別在哪? 並且成功將自己心中的做法實踐出來。過程中因為沒有想清楚就動手，導致卡關了幾天，但也因為這次卡關重新去了解並使用這個工具。

感謝隊友的信任，給我時間進行嘗試!

文章內容如有錯誤，歡迎留言討論！