Part 3｜第 8／30 篇
今日要做的事： 寫 Firebase 安全性規則（Security Rules），用 Emulator 證明 uid-A 讀不到 uid-B。
今天要解決的目的： 隔離靠伺服器規則，不靠「前端沒顯示別人的按鈕」。

Day 6 讓資料有了身份，但還沒證明身份真的能隔離資料。
昨天 Firestore 還在測試模式——誰拿到路徑都能動。
你總不會希望隔壁桌的人偷看你冰箱庫存、順便改你過敏資料吧？XDD
所以今天我要看到紅燈：uid-A 讀 uid-B → 必須被拒絕。

官方怎麼定義這件事：Security Rules 是伺服器端強制執行的規則，用來保護 Firestore／Storage 等資料——不是請前端「乖乖不要亂讀」。文件在這：
https://firebase.google.com/docs/rules?hl=zh-tw

今日任務卡

本機程式：material/code/day7

路線圖

問題：路徑有 uid ≠ 有權限
  → 設計：整棵 users/{userId} 只有本人
  → 寫 firestore.rules
  → CLI 丟進 Emulator 測
  → npm test 五案全過
  → Emulator UI 確認測的是本機
  → （之後）再考慮 deploy 正式專案

1. 問題：前端傳來的 uid 不能當身份

路徑寫成 users/{uid}/daily/... 只是資料夾整理，不會自動產生權限。
client 寫錯或惡意改路徑，照樣可以指向別人的 uid——UI 藏按鈕擋不住會開 DevTools 的人。

真正能信的只有：

request.auth.uid == path 裡的 userId

文件裡的 owner_uid、網址參數、畫面上選到的帳號——都不能替代 Auth token。

為什麼今天一定要測「被拒絕」？

官方文件把 Security Rules 講成「細微的伺服器強制執行規則」。我用工程師白話翻譯成三條，對應今天的測試：

再講白一點：DishFlow 以後會有 pantry、過敏、今天吃了什麼。
那些是個人資料。我不會希望陌生人（或另一個測試帳）把我的庫存當開放 API。
所以今天測的不是「規則檔長得漂不漂亮」，而是——門衛會不會真的把門關上。

今天只解資料隔離。欄位合不合 schema，還是 Part 2 validator 的事；推薦能不能出現某食材，是後面 Agent C 的 hard constraint。

2. 設計：整棵子樹只有本人

v1 私有資料都掛在：

users/{userId}/{document=**}

最低要測這四種情況：

兩道門別搞混：

Rules 全綠，不代表推薦已經安全。

3. 實作：規則很小，測試要兇

3.1 firestore.rules

對應官方說的 Firebase 安全性規則——我這份是套在 Cloud Firestore 上的門衛（同一套概念之後也會用在 Storage）。

這不是 App UI，也不是資料庫裡的某一筆。
路徑長得像屬於某人，不代表別人就不能偷讀。所以我規定：token 裡的 uid 必須等於路徑上的 {userId}，才准動整棵子樹——冰箱、過敏、今日菜單，一律同款門禁。

沒寫到的路徑預設 deny。

rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    // v1：整棵 users/{userId} 子樹只有本人能讀寫
    match /users/{userId}/{document=**} {
      allow read, write: if request.auth != null
                         && request.auth.uid == userId;
    }
  }
}

3.2 規則檔 vs Firebase CLI

規則寫在檔案裡；CLI 負責拿去測或發布：

Console 網頁也能改 Rules，但難跟專案一起版控，也難自動化測跨帳號 deny。
我選：檔案為準 → CLI 測試 → 需要時再 deploy。

3.3 本機資料夾

material/code/day7/
  firestore.rules          ← 門衛規則
  firebase.json            ← 告訴 CLI 規則在哪、Emulator 埠號
  package.json
  tests/rules.test.js      ← 測試台（不是產品 UI）

測試資料只用 fixture：users/uid-a/...、users/uid-b/...。
seed 才暫時關 rules；正式斷言一律用「假裝已登入 A」／「未登入」的 context。

3.4 怎麼跑測試

cd material/code/day7
npm install
npm test

npm test＝啟動 Firestore Emulator → 跑五案 → 關掉。

Emulator 需要 Java。若出現 Could not spawn java -version，裝好 JDK 後重開終端再跑。

3.5 測試台在測什麼——為什麼這五案有意義

rules.test.js 不是產品畫面，只是專門拿來撞規則的測試台。
官方文件也強調要用模擬器／測試把規則驗證掉；我今天做的就是這件事：假裝不同身份去撞門，看會不會真的被擋。

對照「別偷看我的庫存」心智模型：

const dbA = env.authenticatedContext("uid-a").firestore();
const dbGuest = env.unauthenticatedContext().firestore();

await assertSucceeds(getDoc(doc(dbA, "users", "uid-a", "profile", "main")));
await assertSucceeds(setDoc(doc(dbA, "users", "uid-a", "daily", "fixture-day"), { ok: true }));
await assertFails(getDoc(doc(dbA, "users", "uid-b", "profile", "main")));
await assertFails(
  setDoc(doc(dbA, "users", "uid-b", "daily", "fixture-day"), { owner_uid: "uid-a" })
);
await assertFails(getDoc(doc(dbGuest, "users", "uid-a", "profile", "main")));

跑的時候若冒出 PERMISSION_DENIED，那是跨帳號被擋的 log——測試預期如此，不是失敗。

4. Emulator UI：本機假控制台

npm run emulators 之後，瀏覽器開 http://127.0.0.1:4000，就是 Firebase Emulator Suite UI。
我這次畫面裡 Firestore 是 On / Port 8080，其餘服務 Off——今天本來就只開 Firestore。

它是本機的「假 Firebase 控制台」：資料跑在 Emulator 裡，不是正式專案 dishflow 的雲端。頁面上的黃條也寫了 local environment。

Terminal 偶爾出現 demo-no-project、firebase login 之類提示，本地測 Rules 可以略過，不影響今天的斷言。

5. 翻車提醒

1. 整支測試包在 withSecurityRulesDisabled()——那只適合 seed。
2. 只測讀、忘了測跨 uid 寫。
3. Emulator 全綠就以為正式環境已安全——還要另外 deploy Rules；本地通過與已發布是兩件事。
4. 為了省事寫 allow read: if true——等於回到測試模式。

6. 今日結論

1. 今天玩的就是官方的 Firebase Security Rules——伺服器端門衛，不是前端禮貌。
2. uid 隔離靠 token 比路徑；你總不會希望別人偷看你的庫存吧。
3. npm test 證明紅燈會亮；Emulator UI 證明測的是本機。
4. 本地通過 ≠ 正式專案已換掉測試模式。

下一篇： 把餐點照片放進相同 uid 邊界的私有 Storage，並保留無照片的手動後門。

附錄 A：素材對照

附錄 B：firebase.json（節錄）

{
  "firestore": { "rules": "firestore.rules" },
  "emulators": {
    "firestore": { "host": "127.0.0.1", "port": 8080 },
    "ui": { "enabled": true, "port": 4000 }
  }
}

附錄 C：今天狀態

1. [x] npm install
2. [x] Java 可用
3. [x] npm test 五案全過
4. [x] rules／terminal／Emulator UI 留證