顯示身份狀態
畫面清楚標示 mock user 或未登入，不讓狀態只藏在變數裡。
CHAPTER 25 · 120 MINUTES
身份、uid 與權限模型（概念模擬）
本章使用課次 25 後 120 分鐘，聚焦 mock 身份、owner uid 與 Rules 邊界；標準練習是概念模擬，不是真實登入。
1個固定 mock uid
3個明確任務
2層權限檢查
LEARNING GOALS
本章結束時，你能做出什麼
完成模擬登入
輸入示範帳號後取得固定 mock uid，知道這不是真正認證。
判斷資料權限
只有 current uid 等於 owner uid 時才能編輯。
進場檢核與作品接力
- 具備第 24 章成果：完成可追蹤、可取消、可模擬訂閱失敗並重試的 memory adapter 即時留言原型，不冒充 Firebase：不看答案，展示或口述第 24 章成果，並說出一項可見證據。 需要補強時從這裡接回
- 能從 Starter、Checkpoint 與 Solution 中辨識目前工作階段：開啟本章主講義，指出 TASK-01 的修改檔案、可見結果與第一個 Checkpoint。 需要補強時從這裡接回
- 能用「操作後看見什麼」描述驗收證據：閱讀三個任務後，選一題說出操作條件與預期可見結果。 需要補強時從這裡接回
輸入：第 24 章產物：完成可追蹤、可取消、可模擬訂閱失敗並重試的 memory adapter 即時留言原型，不冒充 Firebase
本章輸出：完成明確標示非真實登入的 Auth 與權限概念模擬
產物類型：prototype；後續用途：第 27 章
PROBLEM & ANALOGY
知道是誰，還不等於什麼都能改
第 24 章已讓資料更新；本章回答「現在是誰、能改哪一筆」。authentication 是驗證門禁卡，authorization 是決定可開哪些門，uid 是不可用姓名取代的唯一識別。
本章要解決：同名、隱藏按鈕與前端條件都不能當伺服器安全邊界。
明確聲明：標準 solution 是教學模擬，不會連 Firebase Authentication，也不證明真實登入。
把名詞對回畫面與程式
- authentication
- 回答「現在是誰」，例如目前登入狀態。
- authorization
- 回答「這個人能做什麼」。
- uid
- 不應用姓名或 Email 取代的唯一識別。
- owner uid
- 資料擁有者識別，和目前 uid 比對。
- Rules
- 正式系統在服務端限制資料存取的安全邊界。
SCOPE
今天的學習邊界
能自己完成
登入／登出狀態、固定 mock uid、owner uid 與 canEdit()。
看得懂即可
Firebase Auth state 與 server Rules 才是正式身份和權限邊界。
刻意延後
OAuth provider、密碼保存、完整 Rules 部署與正式帳號生命週期。
Live Extension（選修）：Auth／Rules 正式環境操作與 Network 證據不影響 Mock 必修主線。開啟安全操作手冊
CORE IDEAS
Authentication 與 Authorization 分開
- authentication 回答「現在是誰」，authorization 回答「這個人能做什麼」。
- 名稱與 Email 可能重複或改變；資料所有權要比對唯一 uid。
- 隱藏編輯按鈕只改善介面，不會阻止直接送出請求。
- 正式系統必須由後端或 Firebase Rules 再驗 uid；前端
canEdit()只是教學與 UI 層。 - 標準 mock 帳號與固定 uid 只用來觀察判斷流程。
DEBUGGING & SECURITY
本人與他人的資料都要測
課堂刻意錯誤：只隱藏按鈕仍可直接呼叫修改函式；或用 displayName 判斷，建立同名使用者後發生誤授權。
- 確認 auth state 是未登入還是有固定 mock uid。
- 檢查目前 uid、資料 ownerUid 與
canEdit()比對結果。 - 分別操作本人與他人資料，不只測成功路線。
- 確認未登入與非 owner 都被拒絕，UI 文案不宣稱真 Firebase。
- Live 延伸必須另外用 Rules 測試器驗證伺服器拒絕，不能只看按鈕。
登出後仍可編輯
先查：查 auth state 是否清成未登入，再查 UI 與 canEdit。
同名的人被誤授權
先查：用目前 uid 與 owner uid 比對，不用 displayName。
按鈕藏起來仍能改
先查：直接呼叫修改流程；前端隱藏不是伺服器權限。
PRACTICE CONTRACT
Starter 到 Solution 共用同一套 mock 身份
開始前先確認這四件事
- 我知道這章是 mock user，不是真 Firebase Authentication。
- 我已準備未登入、本人與他人三條路線。
- 權限判斷使用 uid，不使用姓名或 Email。
- 我會把前端限制與正式 Rules 邊界分開說。
呈現登入與登出狀態
檔案：script.js
位置：renderAuthState()
結果：畫面清楚顯示目前 mock user 或未登入
完成教學模擬登入流程
檔案：script.js
位置：mockSignIn()
結果：空白與錯誤 Email 不會登入，示範帳號取得固定 mock uid
以 uid 判斷資料權限
檔案：script.js
位置：canEdit()
結果：只有資料 owner uid 可編輯
EVIDENCE
成果證據與真實系統邊界
30 秒說法可以直接照這個句型練習：
authentication 說明 ______；authorization 由 ______ 判斷；目前 uid ______ 與 owner uid ______ 的結果是 ______。
標準 solution 是概念模擬；不要把隱藏按鈕或 mock uid 描述成正式安全機制。
提交未登入、本人可編輯、他人不可編輯三張畫面；口頭分清 authentication、authorization、uid 與 owner uid。
下一章：把唯一 id、render 與 localStorage 合成完整 TODO CRUD。