上一課結束時，你的 App 已經認得你是誰了（Authentication）。但這只解決了一半。使用者只要在網址列直接敲 your-app.com/dashboard，就能繞過你精心做的登入按鈕，瀏覽器不會幫你問「這個人登入了嗎」。這一課要請一位 網站保全 站在每一個請求的門口：登入的人放行，沒登入的人請回登入頁。這就是 Authorization 的邊界：把「你能進哪裡」這條線畫出來。
先看一個 AI demo 最常見的洞：登入按鈕做得漂亮，但 /dashboard 直接打網址就進得去。你自己來闖一次。
/dashboard、/settings、後台。被直接打開時必須先驗身分。/、定價頁 /pricing、還有登入頁 /login 自己。這些不該擋。/dashboard、/admin 直接打網址就進得去。本機自己玩看不出來，因為你一直是登入狀態。在請求碰到頁面之前，先攔下來檢查一次。框架叫它 middleware，心智模型就是「保全」。
保全上班：送出請求看看，它會在保全處被攔下。
關鍵在位置：保全站在頁面被渲染之前。所以擋下未登入者的時候，私密資料根本還沒被讀出來，更別說傳給對方。這跟「頁面自己跳出一個『請先登入』的彈窗」完全不同，那時候資料早就送到瀏覽器了。
保全不是看你長相，是看你手上那張 6-14 拿到的 Session 還有效嗎。
your-app.com/dashboard，會發生什麼？同一個請求，檢查通過直接進頁面，檢查失敗就被導回登入頁。挑個身分，自己走兩遍。
同一個請求、同一道保全，差別只在手上那張 Session。檢查通過放行，失敗就導回登入頁，這條「能進 / 不能進」的界線就是 Auth Boundary（授權邊界）。
不是每頁都要擋。哪些公開、哪些要登入，是你給保全的一張名單。自己分類看看。
/api/orders 這種 API route 也要保全，否則有人不開畫面、直接打那個網址，一樣把訂單資料整包撈走。保全要同時站在「畫面門口」和「資料門口」。你不會一條一條手寫「/dashboard 要擋、/dashboard/orders 也要擋」。框架讓你寫一條樣式（pattern）一次涵蓋一整區，例如「/dashboard 開頭的全部都算受保護」。
export const config = { matcher: ['/dashboard/:path*', '/settings/:path*', '/api/:path*'], }
:path* 是「後面接什麼都算」。一行就把整個 /dashboard 底下、整個 /api 底下全納進保全的管轄。名字和語法各框架不同，概念一樣：用樣式描述「哪一區要過保全」。
/admin 後台頁，但忘了把它加進保護名單。哪一種預設策略能讓這個疏忽「比較不致命」？AI 很會做登入按鈕，常常忘記做保全。這一節把整課收成你跟 AI 開需求要交代的幾件事。
/dashboard 擋住了，但 /api/orders 還是裸奔，有人直接打那個網址一樣把資料撈走。保全只站在「畫面門口」，沒站在「資料門口」。現在沒登入的人進不來了，門口的保全也站好了。但登入進來的人，看到的應該是他自己的資料，不是別人的。小明不該看到小華的訂單。下一課我們把使用者和他的資料關聯起來，讓每個人登入後只看得到屬於自己的那一份。