上一課結束時，你的 App 已經認得你是誰了（Authentication）。但這只解決了一半。使用者只要在網址列直接敲 your-app.com/dashboard，就能繞過你精心做的登入按鈕，瀏覽器不會幫你問「這個人登入了嗎」。這一課要請一位 網站保全 站在每一個請求的門口：登入的人放行，沒登入的人請回登入頁。這就是 Authorization 的邊界：把「你能進哪裡」這條線畫出來。
先看一個 AI demo 最常見的洞：登入按鈕做得漂亮，但 /dashboard 直接打網址就進得去。你自己來闖一次。
/dashboard、/settings、後台、別人的私密資料。這些頁面被直接打開時，必須先確認身分。/、定價頁 /pricing、還有登入頁 /login 本身。這些不需要、也不能擋。/dashboard、/admin 直接打網址就進得去。本機自己玩看不出來，因為你一直是登入狀態。在請求碰到頁面之前，先攔下來檢查一次。框架叫它 middleware，心智模型就是「保全」。
每次有人想看你的頁面，瀏覽器都會送出一個請求（request）。Middleware 就是一段「在請求真正碰到頁面之前，先攔下來跑一次」的程式。位置才是重點：它站在門口，而不是房間裡。
名字會因框架而異，在 Next.js 它叫 middleware，Express 也有自己的 middleware，其他框架有對應的攔截機制。名字不重要，重要的是這個位置：請求到頁面之前的那道門。
保全上班：送出請求看看，它會在保全處被攔下。
關鍵在位置：保全站在頁面被渲染之前。所以擋下未登入者的時候，私密資料根本還沒被讀出來，更別說傳給對方。這跟「頁面自己跳出一個『請先登入』的彈窗」完全不同，那時候資料早就送到瀏覽器了。
保全不是看你長相，是看你手上那張 6-5 拿到的 Session 還有效嗎。
還記得 6-5 登入成功後，瀏覽器拿到的那張 access token（Session）嗎？保全要的就是它。每個請求都帶著這張證走到門口，保全檢查三件事：
① 有沒有這張證 ② 簽章是不是 Firebase 發的（沒被偽造）③ 有沒有 過期（exp 還沒到）。三項都過才放行。
your-app.com/dashboard，會發生什麼？同一個請求，檢查通過直接進頁面，檢查失敗就被導回登入頁。挑個身分，自己走兩遍。
同一個請求、同一道保全，差別只在手上那張 Session。檢查通過放行，失敗就導回登入頁，這條「能進 / 不能進」的界線就是 Auth Boundary（授權邊界）。
不是每頁都要擋。哪些公開、哪些要登入，是你給保全的一張名單。自己分類看看。
你可以叫保全用兩種策略：黑名單（預設全開，只擋你列出來的）或 白名單（預設全擋，只放行你列出來的公開頁）。
白名單更安全。因為哪天你新增一頁忘了標記，白名單下它是「不小心被擋住」（使用者抱怨進不去），黑名單下它卻是「不小心全世界可見」（資料外洩）。錯，也要錯在安全的那一邊。
/api/orders 這種 API route 也要保全，否則有人不開畫面、直接打那個網址，一樣把訂單資料整包撈走。保全要同時站在「畫面門口」和「資料門口」。/admin 後台頁，但忘了把它加進保護名單。哪一種預設策略能讓這個疏忽「比較不致命」？AI 很會做登入按鈕，常常忘記做保全。這一節把整課收成你跟 AI 開需求要交代的幾件事。
/dashboard 擋住了，但 /api/orders 還是裸奔，有人直接打那個網址一樣把資料撈走。保全只站在「畫面門口」，沒站在「資料門口」。現在沒登入的人進不來了，門口的保全也站好了。但登入進來的人，看到的應該是他自己的資料，不是別人的。小明不該看到小華的訂單。下一課我們把使用者和他的資料關聯起來，讓每個人登入後只看得到屬於自己的那一份。