JWT

前言：帳密明明正確，卻回 500 某天收到回報：使用者從手機點開官網登入，帳號密碼都對，卻跳出 Internal Server Error。換其他瀏覽器再登入就成功了。 「帳密正確卻 500」這種錯誤特別惱人，因為它不是身分驗證的問題，而是驗證通過之後才出事。本文記錄怎麼從一行日誌追到根因，以及背後三個值得每個後端工程師記住的設計教訓。 從日誌追根因：三條線索 先分清楚登入失敗的兩種回應：帳密錯誤會回 400 Invalid identifier or password；而這次是 500。光這一點就暗示——帳密其實是對的，問題出在登入流程的後半段。 線索一：500 只在帳密正確時出現 撈出該帳號當天的登入紀錄，發現 500 全部集中在某個時段，之後突然出現一次成功，再之後才是幾筆「帳密錯誤」的 400。換句話說，那串 500 本身就證明了帳密一直是對的——錯的不是驗證。 線索二：那行 PostgreSQL 錯誤訊息 日誌裡每筆 500 都附帶同一句資料庫錯誤： insert into "refresh_tokens" (..., "user_agent") values (...) - value too long for type character varying(255) 真相浮現：登入驗證通過後，後端要寫一筆 refresh token 進資料庫，其中 user_agent 欄位是 varchar(255)，而這次要寫入的值超過 255 字元，PostgreSQL 直接拒絕，未被攔截的例外往上冒成了 500。 線索三：為什麼有時成功、有時失敗 成功那次寫進資料庫的 user_agent 長度是 128；失敗那幾次的值都超過 255。差別就在 User-Agent 字串的長度——而它由「使用者用什麼瀏覽器」決定。 根本原因：varchar(255) 塞不下 in-app 瀏覽器的 UA 寫入 refresh_tokens 的欄位中，token 是固定長度的隨機字串、expires_at 是時間、device_type 是短列舉、ip_address 也很短。唯一長度會劇烈變動、且可能爆掉的，只有 user_agent。 ...

結帳頁突然報錯：Missing or invalid credentials 使用者在 App 內開啟網頁版結帳頁，輸入折扣碼後收到一個刺眼的錯誤訊息：「Missing or invalid credentials」。 不是每個人都遇到，也不是每次都發生。但只要在頁面上停留超過一段時間再操作，就一定會觸發。 聽起來很熟悉？沒錯，這跟前一篇文章的問題同源——JWT 15 分鐘過期。差別在於，上次是後端的 refresh API 被權限系統擋掉，這次是前端根本沒有呼叫 refresh 的能力。 架構背景：App 開網頁的 SSO 流程 我們的 Flutter App 會透過 in-app browser 開啟 Vue 網頁。token 的傳遞方式很直接： https://web.example.com/checkout/xxx?token=eyJhbG... Vue 從 URL query param 取得 JWT，存進 sessionStorage，之後的 API 呼叫都帶這個 token。 問題在於：只傳了 JWT，沒有傳 refresh token。 JWT 有 15 分鐘的壽命。使用者開啟頁面、慢慢填寫發票資料、比較方案——15 分鐘一晃就過了。接下來任何 API 呼叫都會收到 401，但 Vue 手上沒有 refresh token，無法換新的 JWT。只能眼睜睜看著使用者被擋在門外。 為什麼 Flutter 不需要擔心，但 Vue 必須處理 Flutter App 本身有完整的 token refresh 機制：interceptor 攔截 401、用 refresh token 換新 JWT、重送失敗的 request。整個流程無縫，使用者無感。 ...

症狀：App 開啟 15 分鐘後被強制登出 使用者回報一個詭異的問題：App 正常使用一段時間後，突然被強制登出。重新登入後又好了，但過一陣子又被踢出去。 時間規律很明確——正好 15 分鐘。這恰好是我們 JWT 的過期時間。 直覺反應是去查前端的 token refresh 邏輯：interceptor 有沒有正確攔截 401？refresh token 有沒有正確儲存？重試機制有沒有 bug？ 查了一輪，全部正常。 錯誤的除錯方向 這個問題前前後後花了不少時間，方向一直在前端打轉： 排查方向 結果 Flutter interceptor 邏輯 正常，有攔截 401 並觸發 refresh Token 儲存機制（SecureStorage） 正常，refresh token 有正確保存 JWT 過期時間設定 確認是 15 分鐘，符合預期 網路連線問題 排除，其他 API 都正常 每個環節看起來都沒問題，但結果就是 refresh 失敗。問題出在哪？ 轉折點：看 HTTP Status Code 直到有人（或者說，終於有人）去看了 /auth/refresh 實際回傳的 HTTP status code： # JWT 過期後呼叫 refresh curl -X POST https://api.example.com/api/auth/refresh \ -H "Content-Type: application/json" \ -d '{"refreshToken": "valid-refresh-token-here"}' # 預期：200 OK（新的 JWT） # 實際：403 Forbidden 403，不是 401。 ...

故事的開始：會員資料集體消失事件 最近收到許多會員的反映，問題驚人地一致： 📝 「我的日記資料不見了！」 👤 「帳號被自動登出，要重新登入」 ⏳「App 一直轉圈圈，什麼都看不到」 😰 「重新開啟 App 也一樣，資料都不見了」 更詭異的是，這些問題似乎沒有規律性，有的使用者正常，有的使用者卻深受其擾。身為技術負責人，這讓我立刻警覺：這不是資料遺失，而是認證機制出問題了。 調查過程：抽絲剝繭找出真相 問題時間軸 gantt title 問題調查時程 dateFormat HH:mm section 發現問題 接獲使用者回報 :a1, 00:00, 30m section 初步調查 檢查資料庫完整性 :a2, 00:30, 20m 分析回報時間規律 :a3, 00:50, 30m section 深入分析 檢查 JWT 配置 :a4, 01:20, 15m 確認根本原因 :a5, 01:35, 10m 第一步：確認資料庫完整性 我的第一個懷疑是資料庫是否真的遺失資料。登入後台查詢，發現： ✅ 關鍵發現： 所有會員的日記資料都完好無缺 這代表問題不在資料層，而是在存取權限上。 第二步：檢查使用者行為模式 整理會員回報的時間點，我發現一個規律： 會員 註冊時間 問題發生時間 間隔 會員 A 30 天前 今天 30 天 會員 B 29 天前 今天 29 天 會員 C 3 天前 正常使用 - 關鍵字：30 天 ⚡ ...