耐人尋味 FoodSelector 美食選擇器

CHALLENGE

權限中介層有一個靜默的繞過:hasPermission() 在 token 無效時 return response()->json([...], 401),而呼叫端只把它當布林判斷——JsonResponse 物件恆為真,於是「沒帶 token」和「帶壞 token」都會直接通過 12 條受保護路由。

SOLUTION

把認證與授權拆開:先 verifyToken() 取回 private id,失敗直接 401;拿到 id 才進 hasPermission(),它現在只回傳純布林,失敗回 403。並補上路由層的 PHPUnit 測試,逐條斷言那 12 條路由掛著正確的 check.permission:<action>、公開路由則不得帶任何權限中介層——測試已寫好,但因為本機沒有 PHP 而尚未實跑。

CHALLENGE

帳號鎖定看起來做完了,實際上從未生效過:locks.status 是字串欄位,程式卻用 === 1 這個型別嚴格的整數比較,永遠為假;而且 add() 建立新列時根本沒寫入 status。

SOLUTION

改成與 '1' 字串比較,並讓 add() 明確寫入 '0'。修好之後,把真實行為畫成狀態機而不是寫成宣傳詞:因為 checklock() 跑在 attempt() 之前,計數必須已達 5,鎖是在第 6 次嘗試才跳;離開鎖定的唯一路徑是答對兩題安全問題重設密碼,沒有管理員解鎖、沒有 TTL、也沒有排程任務。

CHALLENGE

RBAC 有四張表、有中介層、有權限字串,卻不可能通過:RoleSeeder 其實是 PermissionsSeeder 的複製品,一個角色都沒有建立,也沒有寫入 role_permissions 與 user_roles——所以每一條受權限保護的路由都必然 403。

SOLUTION

重寫 RoleSeeder:建立 buyer / seller 兩個角色,依 action_name 查出 permission id 對映 role_permissions,再指派 user_roles,並補上買家的 member 列;DatabaseSeeder 改成外鍵安全的順序。另外補回一個從來沒有 migration 建立過的 collect 表——收藏功能所依賴的表其實不存在。這些修復目前只有原始碼佐證,沒有實跑遷移與 seeder 的紀錄。

CHALLENGE

要在沒有 PHP、沒有 MySQL 的環境裡把整個產品操作一遍——不論是 GitHub Pages 上的展示,還是自己開發前端時。

SOLUTION

所有資料存取收斂成一層 adapter(12 個匯出函式),以 VITE_API_MODE 切換 demo / live,兩條分支回傳同樣的形狀;demo 分支連後端的怪癖都照抄(/product/info/{id}/ 回傳單元素陣列),日後切回 live 不必動元件。39 個 Vitest 案例大多是在守這層。但 parity 並不完美,而且是已知的:demo 分支會過濾 products.status === 1(種子 26 道菜、上架 25 道,所以畫面顯示「菜色 25」),真實後端的 /search/ 與兩條隨機路由都沒有這個條件;前端向 adapter 要 8 家店 / 12 道菜當候選池,live 模式卻永遠只會拿到後端固定的 4 筆。這些落差列在已知問題,而不是假裝不存在;而且不只這兩處——demo 的搜尋還會比對描述欄,後端則只比對名稱。