讓網站內容自己更新 · 第 02 章
後台要確認誰能改什麼
登入、編輯與發布是不同能力，每次後端請求都要檢查。
貓老闆的簡報
店員可以修錯字，不代表每個人都能刪文章、改權限或發布新品。
——貓掌櫃官網的老闆「掌櫃」下需求時的原話
這章做什麼
建立測試編輯者與管理者的操作範圍，保護內容 API。
動手做
- 沿用成熟登入方案，規劃訪客不能進後台、編輯者能存草稿、管理者能發布與封存的最小角色表。
- 後端對新增、讀取草稿、修改、發布、封存與圖片操作逐一檢查權限，不只隱藏選單。
- 若使用 Cookie 登入，沿用框架的請求防護與安全設定，避免外站借用登入狀態執行修改。
- 用兩個不同角色測試直接呼叫 API、改內容識別及登出後重試；不應有權限時，確認資料真的沒被改。
親手試試
模擬：能編輯與預覽草稿，無法透過 API 自行升權或發布。
模擬：確認身分與權限後才可發布或封存，操作留下紀錄。
這是角色示範，不建立真實帳號或存取控制。
這樣對 AI 說
中文就可以
請沿用目前登入機制，為內容後台加入最小角色表：訪客無後台權限，編輯者存草稿，管理者發布與封存。每次內容及圖片 API 在後端驗證身分和操作權限，Cookie 登入沿用框架的請求防護。以不同測試帳號檢查直接呼叫 API、變更內容識別及登出後操作，記錄拒絕結果與資料未變更的證據。
本章驗收清單
請在自己的練習專案實際操作，再依結果逐項確認。
- 角色能力有明確對照
- 草稿 API 不對外公開
- 直接呼叫 API 仍受權限保護
- 拒絕操作後資料未被修改
這章的相關詞條
詞條頁都有可以動的示範——卡住的時候，去把名詞弄清楚，回來繼續做。
官方參考資料
進度只存在這台瀏覽器，不上傳、不追蹤。