Cloudflare Workers 与 Access：支持在 Worker 上启用 Access
Workers, Access - You can now enable Access on a Worker or all Workers at once
对于依赖 Cloudflare Workers 的开发者，这是一次重要的能力扩展：现在可以更简单地保护 Worker 应用，尤其是默认私有化功能，能显著提升安全性。建议立即了解并配置，特别是涉及敏感数据的 Worker。
You now have two new ways to protect your Workers with Cloudflare Access.
您现在有两种新方法可以使用 Cloudflare Access 保护您的 Workers。
Protect an application across all its domains at once
一次保护跨所有域名的应用程序
Until now, if a Worker was reachable on a route, a Custom Domain, and a workers.dev URL, you had to manually add each one to an Access application and keep the list in sync whenever routes or domains changed.
到目前为止，如果 Worker 可以通过路由、自定义域名和 workers.dev URL 访问，您必须手动将每个添加到 Access 应用程序中，并在路由或域名更改时保持列表同步。
Now, Access attaches the policy to the Worker itself, so every associated domain and preview URL stays protected even when its routes or domains change.
现在，Access 将策略附加到 Worker 本身，因此即使其路由或域名更改，每个关联的域名和预览 URL 也保持受保护。
Protect all new and existing Workers by default
默认保护所有新 Worker 和现有 Worker
Make all Workers private by default, so every existing and newly created Worker requires sign-in before anyone can reach it.
默认将所有 Worker 设为私有，以便每个现有和新创建的 Worker 在任何人可以访问之前都需要登录。
If a specific Worker should remain publicly accessible, add a Worker-level bypass to exempt it.
如果特定 Worker 应保持公开可访问，请添加 Worker 级绕过以豁免它。
Whether you protect a single application or all Workers at once, you can choose whether to protect preview deployments only or both previews and production, and control who can sign in by Cloudflare account membership, email address, or email domain.
无论您是保护单个应用程序还是同时保护所有 Worker，您都可以选择仅保护预览部署还是同时保护预览和生产，并通过 Cloudflare 账户成员资格、电子邮件地址或电子邮件域控制谁可以登录。
For more advanced policy options, edit the policy in Zero Trust ↗.
有关更高级的策略选项，请在 Zero Trust ↗ 中编辑策略。
View all of your Worker Access policies
查看所有 Worker Access 策略
You can view and manage all of your Access policies in the Access tab of the Workers & Pages section in the dashboard.
您可以在仪表板的 Workers & Pages 部分的 Access 选项卡中查看和管理所有 Access 策略。
See who is accessing your Worker
查看谁在访问您的 Worker
When Access is enabled on your Worker, every authenticated request includes ctx.access. Call ctx.access.getIdentity() to get the user's email, name, and groups — no manual JWT validation required.
当您的 Worker 上启用 Access 时，每个经过身份验证的请求都包含 ctx.access。调用 ctx.access.getIdentity() 获取用户的电子邮件、姓名和组——无需手动验证 JWT。
export default {
async fetch(request, env, ctx) {
if (!ctx.access) {
return new Response("Access did not run", { status: 401 });
}
const identity = await ctx.access.getIdentity();
return Response.json({ aud: ctx.access.aud, email: identity?.email });
},
};export default {
async fetch(request, env, ctx) {
if (!ctx.access) {
return new Response("Access did not run", { status: 401 });
}
const identity = await ctx.access.getIdentity();
return Response.json({ aud: ctx.access.aud, email: identity?.email });
},
};Test Access locally
在本地测试 Access
You can now test Cloudflare Access locally with wrangler dev. Add a dev block to your wrangler.jsonc:
您现在可以使用 wrangler dev 在本地测试 Cloudflare Access。在您的 wrangler.jsonc 中添加一个 dev 块：
{
"access": {
"dev": {
"aud": "my-app",
"identity": { "email": "[email protected]" }
}
}
}{
"access": {
"dev": {
"aud": "my-app",
"identity": { "email": "[email protected]" }
}
}
}Your Worker will receive this identity through ctx.access and ctx.access.getIdentity(), letting you test authenticated and unauthenticated flows without deploying. Remove the dev block to simulate unauthenticated requests.
您的 Worker 将通过 ctx.access 和 ctx.access.getIdentity() 接收此身份，让您无需部署即可测试已认证和未认证的流程。移除 dev 块以模拟未认证的请求。
API and programmatic access
API 和编程访问
You can also set up these policies through the Workers API instead of the dashboard.
您也可以通过 Workers API 而不是仪表板来设置这些策略。
更进一步：量化金融体系
看懂新闻只是起点——沿量化金融路径，把它变成能交付的工程能力