Cloudflare Workers 怎麼套 Access？用 Worker scope 保護所有入口

Worker-level 與 account-wide 是兩種不同策略#

Cloudflare 目前提供兩種操作方向：

無論選哪一種，官方都讓你決定保護 preview deployments，或同時保護 preview 與 production。這個選項要和部署流程一起記錄，因為測試網址可能有不同的資料來源與 callback 設定。

如果你的問題只是「Preview URL 怎麼關或限制」，可以先看 Cloudflare Workers Preview URL 的公開範圍與 Access 檢查。本文聚焦新版 Worker scope 與全帳號預設保護，不取代 Preview URL 本身的開關。

先選保護範圍，再到 Dashboard 設定#

建議先用這個決策順序：

1. 列出要保護的 Worker，以及它目前對外的 route、Custom Domain、workers.dev 和 preview 入口。
2. 只有一個內部 Worker 時，優先使用單一 Worker 的 Access 設定，避免把不相關的公開服務一起鎖住。
3. 如果組織要求新舊 Worker 都必須登入，才選 account-wide default，再為明確要公開的 Worker 加 bypass。
4. 分開決定 preview-only 或 preview + production，並用測試帳號驗證兩種部署入口。
5. 到 Workers & Pages 的 Access 區域查看目前所有 Worker policies，確認實際生效的清單。

這裡不要把「帳號預設保護」當成應用程式內的角色系統。Access 先處理誰能抵達 Worker；Worker 自己仍要決定通過身份後能讀哪些資料、呼叫哪些 API，以及不同環境使用哪一組 binding。

在 Worker 內讀取 Access identity#

Access 啟用後，Cloudflare 會在已驗證的請求提供 ctx.access。官方範例用 ctx.access.getIdentity() 取得 email、name 和 groups；可以在自己的 Worker 加入最小回應，先確認身份邊界是否如預期：

1
export default {
2
  async fetch(request, env, ctx) {
3
    if (!ctx.access) {
4
      return new Response('Access did not run', { status: 401 });
5
    }
6

7
    const identity = await ctx.access.getIdentity();
8

9
    return Response.json({
10
      aud: ctx.access.aud,
11
      email: identity?.email,
12
    });
13
  },
14
};

這段程式的用途是驗證 Access 是否執行，不是把 email 當成完整授權規則。正式 API 仍應依照你的角色、群組和資料邊界處理權限；也不要把完整 identity 直接回傳到公開端點。

用 wrangler dev 測試登入與未登入兩條路徑#

Cloudflare 這次也提供本機 Access 測試設定。在 wrangler.jsonc 的 dev 區塊加入測試 identity：

1
{
2
  "access": {
3
    "dev": {
4
      "aud": "my-app",
5
      "identity": {
6
        "email": "[email protected]"
7
      }
8
    }
9
  }
10
}

接著在 Worker 專案執行：

1
wrangler dev

先用測試 identity 確認 ctx.access.getIdentity() 回傳預期內容，再移除 dev 區塊重新啟動，模擬沒有 Access identity 的請求。這樣可以在部署前分開驗證「已驗證請求」與「Access 沒有執行」的程式分支，不必把每一次錯誤都歸因於 Dashboard policy。

注意 dev 設定只服務本機測試。它不會替 production 建立 Access application，也不應放入會被提交的真實使用者資料或 token。

部署後的驗證清單#

完成設定後，至少留下以下結果：

如果某個入口仍然可以匿名抵達，先回到 Worker scope、preview 選項與 bypass 清單檢查。不要只在 Worker 程式裡加一個 Authorization header 判斷，因為那會把平台入口的設定問題和應用層授權混在一起。

結論：把「所有入口」當成同一個 Worker 邊界檢查#

新版 Cloudflare Workers Access 的價值，是讓保護政策可以綁定 Worker，而不是只綁一個當下知道的網址。單一 Worker 適合精準控管內部服務；account-wide 適合把「預設私有」變成組織政策，但公開例外必須明確設定 bypass。最後用 wrangler dev 測試有、無 identity 的路徑，再到 production 逐一驗證 route、網域與 preview。

常見問題#