能登入，與有權操作，是兩件事

登入與權限常會碰到兩個名詞：**Authentication（身分認證）**在登入時確認你是誰；**Authorization（授權）**判斷你能做哪些操作、能處理哪些資料。

以使用Cookie維持登入的訂單後台為例，登入成功後，瀏覽器會保存網站發出的登入Cookie。後續讀取或儲存訂單時，瀏覽器依設定帶上Cookie，後端據此辨認登入身分，再判斷是否允許操作。

例如業務人員可以登入，也有修改訂單的權限，但只能修改自己負責客戶的訂單。後端若只確認「已登入」，還不足以決定是否接受修改，也要判斷操作權限與這張訂單的資料範圍。

畫面隱藏按鈕、列表不顯示別人的訂單，都能減少誤操作。但API仍可能被直接呼叫，單筆查詢、修改與匯出也可能走不同的程式路徑。限制要涵蓋這些入口，不能只放在畫面上。

資料欄位也是如此。電話在畫面上被遮住，若API回應仍包含完整電話，資料其實已送到使用者手上。限制取得資料，需要在後端決定哪些內容可以回傳。

權限改了，後端讀到的是新資料嗎？

管理員取消修改權限後，後端如果每次操作都讀取目前權限，可以直接依新狀態判斷。但如果登入後就把權限快取起來，每次操作都讀這份快取呢？

資料庫裡的權限已更新，快取卻可能還保留「允許修改」。使用者原本的編輯頁還開著，再按下儲存，即使後端有檢查權限，仍可能依舊資料放行。

因此，修改權限時也要處理快取的更新或清除。若角色與權限被寫進登入Cookie，則還有另一份登入時的資料；清除伺服器快取，並不會把瀏覽器持有的Cookie一起改掉。

快取能減少重複查詢，但生效時間也受到更新機制影響。如果要求取消權限後，下一次修改請求就被拒絕，只靠等快取或Cookie到期便不夠。

多台Server如果各自保存權限快取，只清除其中一台，其他台仍可能依舊權限放行。常見做法是共用Redis等分散式快取，或在權限變更時通知各台清除本機快取。但共用快取仍需要更新，通知也可能延遲或漏接。若要求取消權限後立即生效，就不能只等快取到期或通知送達，還需要讓後端在接受操作前確認權限是否仍有效。

每次取得最新權限會增加存取成本，沿用快取則多了更新責任。權限檢查放在哪裡固然重要，它使用的資料是否仍有效，同樣會影響結果。

停權不是只擋下一次登入

取消修改權限，不一定要把使用者踢出系統。他仍可能有查詢權限，只要後續操作使用更新後的規則，就能繼續工作。

帳號停權則要處理既有登入。只在登入頁檢查停權狀態，擋得住重新登入的人，卻不一定擋得住昨天就登入、Cookie還有效的人。

登入Cookie可能保存登入時取得的身分資訊，也可能只保存識別碼，讓後端查找登入狀態。在沒有額外檢查帳號狀態或登入是否已撤銷的情況下，後端可能繼續接受尚未到期的Cookie。帳號資料改成停權，不會自動讓每份既有Cookie失效。

一種做法是在處理請求時檢查帳號狀態；另一種是保存登入版本或撤銷狀態，讓後端辨認哪些舊登入已不能使用。若採定期重新檢查，就會有檢查間隔，要符合停權的生效要求。

這些檢查可以集中在共用的登入處理流程，讓各個入口都能拒絕失效的登入，再依各自的操作與資料權限決定是否放行。

踢回登入頁，與後端拒絕，是兩件事

讓畫面收到通知後退出，可以減少使用者繼續操作的困惑。但通知可能未送達，使用者也可能還有另一個裝置開著，不能只依靠前端退出。

一般登出會要求目前的瀏覽器清除登入Cookie，卻不代表其他裝置的Cookie也被清除。若要停止所有既有登入，需要有後端能辨認的撤銷機制，而不只是把某個畫面導回登入頁。

後端先拒絕已停權帳號或被撤銷的登入，前端再顯示提示、回到登入頁。即使舊頁面上的儲存按鈕還在，也不能讓那次修改被接受。

權限管理不只是在資料庫裡改設定，還要讓後續請求不再沿用舊權限。快取多久更新、既有登入如何撤銷，決定了「取消權限」與「實際失去權限」之間會隔多久。

「帳號停權了，還能操作？」
「等他登出後就不行。」