表單到收款：做出能接單的網站 · 第 04 章
登入後只看得到自己的訂單
使用者登入後可以查自己的訂單；管理者才能查全部。每次 API 查詢都要驗證身分與權限。
貓老闆的簡報
客人不能改個網址就看到隔壁桌買了什麼，管理訂單的入口也不能誰都進得去。
——貓掌櫃官網的老闆「掌櫃」下需求時的原話
這章做什麼
採用專案既有登入功能或成熟的身分服務，將訂單綁定登入者，完成使用者與管理者的存取範圍。
動手做
- 請 AI 盤點既有登入方式；若沒有，先選一個適合目前後端的成熟登入方案，依官方文件設定測試帳號，不自行設計密碼儲存方式。
- 建立訂單時，由伺服器從有效登入狀態取得使用者識別，忽略前端傳入的訂單擁有人。
- 訂單查詢、取消與付款 API 都確認訂單屬於目前使用者；管理者另有受保護的查詢入口。只隱藏按鈕並不足夠。
- 用兩個虛構帳號 A、B 練習：A 建立訂單後，B 改網址或直接呼叫 API 仍不能讀取或修改。登出後也不能使用原本頁面繼續操作。
親手試試
模擬：尚未登入，只顯示登入入口，不提供訂單資料。
模擬：可查看 A 的訂單；請求 B 的訂單時，後端拒絕提供資料。
模擬：後端確認管理者角色後，才允許查看待處理訂單。
只是權限情境示意；這裡切換分頁不會真的登入，也不是權限保護的實作。
這樣對 AI 說
中文就可以
請檢查目前登入機制，沿用成熟方案，將訂單綁定到伺服器認定的登入者。查詢、取消和建立付款時都檢查登入與訂單擁有權；一般使用者只能操作自己的訂單，管理者才能查看全部。不要信任前端傳入的使用者識別或角色。請提供兩個虛構測試帳號 A、B 的驗收步驟，包含改網址、直接呼叫 API、登出後繼續操作；記錄預期與實際結果。
本章驗收清單
用別人的帳號測一次，比只看正常畫面更能確認權限。
- 訂單擁有人由後端決定
- B 無法讀取或修改 A 的訂單
- 登出後 API 拒絕訂單操作
- 管理者查詢入口也有後端權限檢查
這章的相關詞條
詞條頁都有可以動的示範——卡住的時候，去把名詞弄清楚，回來繼續做。
進度只存在這台瀏覽器，不上傳、不追蹤。