diff --git a/src/assets/images/workers/access/protect-all-workers-card.png b/src/assets/images/workers/access/protect-all-workers-card.png new file mode 100644 index 00000000000..412a8f4ab04 Binary files /dev/null and b/src/assets/images/workers/access/protect-all-workers-card.png differ diff --git a/src/assets/images/workers/access/worker-access-tab-unprotected.png b/src/assets/images/workers/access/worker-access-tab-unprotected.png new file mode 100644 index 00000000000..0a81ef718bb Binary files /dev/null and b/src/assets/images/workers/access/worker-access-tab-unprotected.png differ diff --git a/src/assets/images/workers/access/worker-identity-linked-resources-blurred.png b/src/assets/images/workers/access/worker-identity-linked-resources-blurred.png new file mode 100644 index 00000000000..41049bfcdbf Binary files /dev/null and b/src/assets/images/workers/access/worker-identity-linked-resources-blurred.png differ diff --git a/src/assets/images/workers/access/worker-level-bypass-public.png b/src/assets/images/workers/access/worker-level-bypass-public.png new file mode 100644 index 00000000000..506feb23128 Binary files /dev/null and b/src/assets/images/workers/access/worker-level-bypass-public.png differ diff --git a/src/content/docs/cloudflare-one/access-controls/applications/choose-application-type.mdx b/src/content/docs/cloudflare-one/access-controls/applications/choose-application-type.mdx index c929e14e7e1..58f18804ae7 100644 --- a/src/content/docs/cloudflare-one/access-controls/applications/choose-application-type.mdx +++ b/src/content/docs/cloudflare-one/access-controls/applications/choose-application-type.mdx @@ -57,6 +57,8 @@ Self-hosted applications can also protect a Cloudflare Worker directly by name, This is the safest and most straightforward way to put authentication in front of a Worker. Instead of configuring individual routes on the Worker and managing authentication at the route level, you link the entire Worker (and optionally its preview deployments) to an Access application. Any request to the Worker on any route passes through Access first. +For Workers-specific setup instructions, refer to [Cloudflare Access for Workers](/workers/configuration/cloudflare-access/). + ### CLI access with cloudflared Self-hosted applications support client-side `cloudflared` authentication. Users can install `cloudflared` on their device and run `cloudflared access login ` from the command line to authenticate through your Access policies without the Cloudflare One Client installed. This is useful for SSH sessions, API calls, and other command-line workflows where a browser-based login flow is impractical. diff --git a/src/content/docs/workers/configuration/cloudflare-access.mdx b/src/content/docs/workers/configuration/cloudflare-access.mdx new file mode 100644 index 00000000000..110d2f6edca --- /dev/null +++ b/src/content/docs/workers/configuration/cloudflare-access.mdx @@ -0,0 +1,256 @@ +--- +pcx_content_type: configuration +title: Cloudflare Access +description: Require sign-in before visitors can reach Cloudflare Workers, preview deployments, or all Workers in an account. +products: + - workers +--- + +import { DashButton, Steps, Tabs, TabItem } from "~/components"; + +Cloudflare Access makes a Worker private by checking each visitor before your Worker runs: allowed visitors reach your Worker, and everyone else gets a login page or has their request blocked. You define who is allowed, such as members of your Cloudflare account or anyone with a verified email address at a domain like `example.com`. + +## Before you start + +To use Access with Workers, you need: + +- A Cloudflare Zero Trust organization set up for the account. If Zero Trust is not turned on, complete [Zero Trust setup](/cloudflare-one/setup/) first, then return to the Workers dashboard. +- Permission to manage Workers and Access applications. + +## Choose what to protect + +Start with what you want visitors to sign in to access, then follow that section below. Each section covers both the dashboard and the API. + +| I want to protect... | Section | API destination type | +| ------------------------------------------------------------- | ------------------------------------------------------------------------------------------- | ------------------------------ | +| Production and preview deployments for **all Workers** | [Protect all Workers](#protect-all-workers) | `all_workers` | +| Preview deployments for **all Workers** | [Protect all Workers](#protect-all-workers) | `all_preview_workers` | +| Production and preview deployments for **one Worker** | [Protect one Worker](#protect-one-worker) | `worker` | +| Preview deployments for **one Worker** | [Protect one Worker](#protect-one-worker) | `preview_worker` | +| One `workers.dev` hostname, Custom Domain, subdomain, or path | [Protect one hostname, Custom Domain, or path](#protect-one-hostname-custom-domain-or-path) | Self-hosted application domain | + +## Protect all Workers + +Protect all Workers when every Worker should require sign-in by default. You can protect all production and preview deployments, or only preview deployments, across every Worker in the account. + + + + +Dashboard path: **Workers & Pages** overview page > **Protect all Workers**. + +![Workers & Pages overview showing the Protect all Workers card above the Workers application list.](~/assets/images/workers/access/protect-all-workers-card.png) + + +1. In the Cloudflare dashboard, go to the **Workers & Pages** page. + + + +2. Find the **Protect all Workers** card. +3. If the card says **Not enabled**, select **Enable Access**. +4. Choose **Production & Previews** or **Previews**. +5. Under **Authentication policy**, select an existing policy or configure one of the [policy options](#policy-options). +6. Select **Enable Access**. + + + + + +Create a self-hosted Access application with an `all_workers` destination to require sign-in for every Worker's production and preview deployments: + +```json +"destinations": [ + { + "type": "all_workers" + } +] +``` + +To protect only preview deployments for every Worker, use `all_preview_workers` instead: + +```json +"destinations": [ + { + "type": "all_preview_workers" + } +] +``` + +Send these `destinations` in a `POST /accounts/{account_id}/access/apps` request. For the full request schema, including [policy options](#policy-options), session settings, and advanced Access options, refer to the [Access applications API](/api/resources/zero_trust/subresources/access/subresources/applications/methods/create/). + + + + +## Protect one Worker + +Protect one Worker when a single Worker should require sign-in. Protection follows the Worker by its ID across all of the Worker's routes, Custom Domains, `workers.dev` hostname, and previews. + + + + +Dashboard path: **Workers & Pages** > select your Worker > **Access**. + +![Worker Access tab showing an unprotected Worker and the Protect this Worker behind Access button.](~/assets/images/workers/access/worker-access-tab-unprotected.png) + + +1. In the Cloudflare dashboard, go to the **Workers & Pages** page. + + + +2. Select your Worker from the application list. +3. Select the **Access** tab. +4. Select **Protect this Worker behind Access**. +5. Choose **Production & Previews** or **Previews**. +6. Under **Authentication policy**, select an existing policy or configure one of the [policy options](#policy-options). +7. (Optional) Review the session duration. +8. Select **Apply Access**. + + + + + +Create a self-hosted Access application with a `worker` destination to require sign-in for one Worker's production and preview deployments. Pass the immutable Worker ID as `worker_id` — this is the Worker tag from the Workers scripts API, or the Worker `id` from the Workers beta API. + +```bash +curl "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/access/apps" \ + --request POST \ + --header "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \ + --json '{ + "type": "self_hosted", + "name": "Access for my-worker", + "destinations": [ + { + "type": "worker", + "worker_id": "c81a2d22c29840ed9d61681a3270dbff" + } + ], + "policies": [ + { + "decision": "allow", + "include": [ + { + "email_domain": { + "domain": "example.com" + } + } + ] + } + ] + }' +``` + +To protect only preview deployments for that Worker, use `preview_worker` instead: + +```json +"destinations": [ + { + "type": "preview_worker", + "worker_id": "c81a2d22c29840ed9d61681a3270dbff" + } +] +``` + +For the full request schema, including [policy options](#policy-options) and session settings, refer to the [Access applications API](/api/resources/zero_trust/subresources/access/subresources/applications/methods/create/). + + + + +## Protect one hostname, Custom Domain, or path + +Use hostname-based Access when only a specific URL that routes to your Worker should require sign-in, such as a `workers.dev` hostname, a Custom Domain, a subdomain, or a path. Hostname-based Access protects only that exact URL, whereas [protecting a Worker](#protect-one-worker) protects the entire Worker. For example, you can protect `my-worker.example.workers.dev`, `admin.example.com`, or a single path such as `example.com/login` to make only part of your Worker private. + +In both the dashboard and the API, you protect a hostname or path by creating a [self-hosted application](/cloudflare-one/access-controls/applications/http-apps/self-hosted-public-app/) and using the hostname or path as the application domain. + + + + +Create the self-hosted application in **Zero Trust** > **Access** > **Applications**. To match subdomains, multiple paths, or wildcards, refer to [Application paths](/cloudflare-one/access-controls/policies/app-paths/). + + + + +Create the self-hosted application with a `POST /accounts/{account_id}/access/apps` request, setting the application domain to the hostname or path. For the full request schema, refer to the [Access applications API](/api/resources/zero_trust/subresources/access/subresources/applications/methods/create/). + + + + +## Make a Worker public when all Workers are protected + +If account-level Access protects all Workers, you can make a specific Worker public by adding a Worker-level bypass. A bypass means Access does not require sign-in for that Worker. + +:::note +This is only useful when account-level Access already protects the Worker. If there is no account-level Access policy, a public Worker does not need a bypass. +::: + + + + +Dashboard path: **Workers & Pages** > select your Worker > **Access**. + +![Manage Worker access dialog showing a Make this Worker public bypass policy.](~/assets/images/workers/access/worker-level-bypass-public.png) + + +1. In the Cloudflare dashboard, go to the **Workers & Pages** page. + + + +2. Select your Worker from the application list. +3. Select the **Access** tab. +4. Select the option to make the Worker public or bypass account-level Access. +5. Confirm the change. + + + + + +Create a more specific Worker-level Access app with a bypass policy. Use the `worker` destination, set `worker_id` to the Worker's immutable ID, and set the policy `decision` to `bypass`. + + + + +## Policy options + +When you turn on Access, choose who can sign in. The same policy options are available whether you protect all Workers or one Worker. + +| Policy option | Result | +| ------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Cloudflare account | Allows members of this Cloudflare account to sign in. Use this option when access should be limited to people who already belong to the account. | +| Email domain | Allows anyone with a verified email address at the domain you enter, such as `example.com`. Use this option when access should be available to people from a company or organization, even if they are not Cloudflare account members. | + +You can add one or more policies. Visitors who match any selected policy can sign in. + +For advanced policy configuration, such as multiple identity providers, device posture rules, service tokens, complex policy ordering, or custom login or block pages, edit the Access application in Zero Trust after you create it. For the full set of options, refer to [Access policies](/cloudflare-one/access-controls/policies/). + +## Disable Access + + + + +To disable Worker-level or account-level Access, open the Worker's **Access** tab or the **Protect all Workers** card and disable the corresponding Access rule. + + + + +Delete the Access application that protects the Worker, all Workers, or the hostname or path that routes to the Worker. + + + + +## Understand Access hierarchy + +A Worker can be protected by more than one Access rule. When multiple rules could apply to the same request, the most specific rule takes effect first: + +1. **Hostname or path-based Access**: Applies first when the request matches that hostname or path, such as `admin.example.com` or `example.com/login`. +2. **Worker-level Access**: Applies next for the selected Worker across its routes, Custom Domains, `workers.dev` hostname, and previews. +3. **Account-level Worker Access**: Applies last as the fallback for all Workers or all Worker previews on the account. + +For example, if a Worker has both account-level Access and a Worker-level rule, the Worker-level rule controls that Worker. If a matching hostname or path-based Access app also exists, that hostname or path rule controls the matching URL. + +If you remove a more specific rule, a broader rule may still protect the Worker. For example, removing Worker-level Access can reveal account-level Access underneath. + +## Related resources + +- [Access applications API](/api/resources/zero_trust/subresources/access/subresources/applications/methods/create/) +- [Access policies](/cloudflare-one/access-controls/policies/) +- [Self-hosted Access applications](/cloudflare-one/access-controls/applications/http-apps/self-hosted-public-app/) +- [Routes and domains](/workers/configuration/routing/) +- [Preview URLs](/workers/configuration/previews/) diff --git a/src/content/docs/workers/configuration/previews.mdx b/src/content/docs/workers/configuration/previews.mdx index 98bdc56c85b..8515e802f5d 100644 --- a/src/content/docs/workers/configuration/previews.mdx +++ b/src/content/docs/workers/configuration/previews.mdx @@ -93,19 +93,13 @@ The resulting alias would be associated with this version, and immediately avail ## Manage access to Preview URLs -When enabled, all preview URLs are available publicly. You can use [Cloudflare Access](/cloudflare-one/access-controls/policies/) to require visitors to authenticate before accessing preview URLs. You can limit access to yourself, your teammates, your organization, or anyone else you specify in your [access policy](/cloudflare-one/access-controls/policies/). +When enabled, Preview URLs are available publicly. To require visitors to sign in before they can access Preview URLs, use [Cloudflare Access](/workers/configuration/cloudflare-access/). -To limit your preview URLs to authorized emails only: +Access can protect previews for one Worker or every Worker in an account. You can also protect both production and preview deployments. -1. In the Cloudflare dashboard, go to the **Workers & Pages** page. - - +For defense in depth, [validate the Access JWT](/cloudflare-one/access-controls/applications/http-apps/authorization-cookie/validating-json/#cloudflare-workers-example) in your Worker code so unauthenticated requests cannot reach your application if Access is ever removed or misconfigured. -2. In **Overview**, select your Worker. -3. Go to **Settings** > **Domains & Routes**. -4. For Preview URLs, click **Enable Cloudflare Access**. -5. Optionally, to configure the Access application, click **Manage Cloudflare Access**. There, you can change the email addresses you want to authorize. View [Access policies](/cloudflare-one/access-controls/policies/#selectors) to learn about configuring alternate rules. -6. [Validate the Access JWT](https://developers.cloudflare.com/cloudflare-one/access-controls/applications/http-apps/authorization-cookie/validating-json/#cloudflare-workers-example) in your Worker script using the audience (`aud`) tag and JWKs URL provided. +To use details about the signed-in user in your Worker, read the [user's identity](/cloudflare-one/access-controls/applications/http-apps/authorization-cookie/application-token/#user-identity) from the validated JWT or the `/cdn-cgi/access/get-identity` endpoint. ## Toggle Preview URLs (Enable or Disable) diff --git a/src/content/docs/workers/configuration/routing/custom-domains.mdx b/src/content/docs/workers/configuration/routing/custom-domains.mdx index df9cf49499d..ac476762cba 100644 --- a/src/content/docs/workers/configuration/routing/custom-domains.mdx +++ b/src/content/docs/workers/configuration/routing/custom-domains.mdx @@ -14,7 +14,7 @@ Custom Domains allow you to connect your Worker to a domain or subdomain, withou Custom Domains are routes to a domain or subdomain (such as `example.com` or `shop.example.com`) within a Cloudflare zone where the Worker is the origin. -Custom Domains are recommended if you want to connect your Worker to the Internet and do not have an application server that you want to always communicate with. If you do have external dependencies, you can create a `Request` object with the target URI, and use `fetch()` to reach out. +Custom Domains are recommended if you want to connect your Worker to the Internet and do not have an application server that you want to always communicate with. If you do have external dependencies, you can create a `Request` object with the target URI, and use `fetch()` to reach out. Custom Domains can stack on top of each other. For example, if you have Worker A attached to `app.example.com` and Worker B attached to `api.example.com`, Worker A can call `fetch()` on `api.example.com` and invoke Worker B. @@ -33,10 +33,8 @@ Custom Domains can be attached to your Worker via the Cloudflare dashboard, [Wra :::caution - You cannot create a Custom Domain on a hostname with an existing CNAME DNS record or on a zone you do not own. - ::: ### Set up a Custom Domain in the dashboard @@ -56,6 +54,12 @@ To set up a Custom Domain in the dashboard: After you have added the domain or subdomain, Cloudflare will create a new DNS record for you. You can add multiple Custom Domains. +### Require sign-in for a Custom Domain + +To require visitors to sign in before they can access a Custom Domain, use [Cloudflare Access](/workers/configuration/cloudflare-access/#require-sign-in-for-one-hostname). + +You can protect a Custom Domain with hostname-based Access, or protect the Worker itself across its routes, Custom Domains, `workers.dev` hostname, and previews. For more information, refer to [Cloudflare Access](/workers/configuration/cloudflare-access/). + ### Set up a Custom Domain in your Wrangler configuration file To configure a Custom Domain in your [Wrangler configuration file](/workers/wrangler/configuration/), add the `custom_domain=true` option on each pattern under `routes`. For example, to configure a Custom Domain: @@ -77,8 +81,6 @@ To configure a Custom Domain in your [Wrangler configuration file](/workers/wran To configure multiple Custom Domains: - - ```jsonc @@ -106,8 +108,8 @@ On the same zone, if a Worker is attempting to communicate with a target Worker For example, consider the following scenario, where both Workers are running on the `example.com` Cloudflare zone: -* `worker-a` running on the [route](/workers/configuration/routing/routes/#set-up-a-route) `auth.example.com/*`. -* `worker-b` running on the [route](/workers/configuration/routing/routes/#set-up-a-route) `shop.example.com/*`. +- `worker-a` running on the [route](/workers/configuration/routing/routes/#set-up-a-route) `auth.example.com/*`. +- `worker-b` running on the [route](/workers/configuration/routing/routes/#set-up-a-route) `shop.example.com/*`. If `worker-a` sends a fetch request to `worker-b`, the request will fail, because of the limitation on same-zone fetch requests. `worker-a` must have a service binding to `worker-b` for this request to resolve. @@ -115,9 +117,9 @@ If `worker-a` sends a fetch request to `worker-b`, the request will fail, becaus export default { fetch(request) { // This will fail - return fetch("https://shop.example.com") - } -} + return fetch("https://shop.example.com"); + }, +}; ``` However, if `worker-b` was instead set up to run on the Custom Domain `shop.example.com`, the fetch request would succeed. @@ -142,15 +144,15 @@ For example, consider the following workflow: ```js title="auth-worker" {8} export default { fetch(request) { - const url = new URL(request.url) - if(url.searchParams.get("auth") !== "SECRET_TOKEN") { - return new Response(null, { status: 401 }) + const url = new URL(request.url); + if (url.searchParams.get("auth") !== "SECRET_TOKEN") { + return new Response(null, { status: 401 }); } else { // This will invoke `api-worker` - return fetch(request) + return fetch(request); } - } -} + }, +}; ``` ## Certificates @@ -170,10 +172,10 @@ Because Custom Domains require an exact hostname match, a Worker attached to `ex - [Redirect from www to root](/rules/url-forwarding/examples/redirect-www-to-root/) - [Redirect from root to www](/rules/url-forwarding/examples/redirect-root-to-www/) -You also need a [proxied DNS record](/dns/manage-dns-records/how-to/create-dns-records/) for the hostname you are redirecting *from*, so that Cloudflare can apply the redirect rule. +You also need a [proxied DNS record](/dns/manage-dns-records/how-to/create-dns-records/) for the hostname you are redirecting _from_, so that Cloudflare can apply the redirect rule. - - For www to root: Add a proxied DNS `A` record for `www` pointing to `192.0.2.0`, or a proxied `AAAA` record pointing to `100::` - - For root to www: Add a proxied DNS `A` record for your root domain pointing to `192.0.2.0`, or a proxied `AAAA` record pointing to `100::` +- For www to root: Add a proxied DNS `A` record for `www` pointing to `192.0.2.0`, or a proxied `AAAA` record pointing to `100::` +- For root to www: Add a proxied DNS `A` record for your root domain pointing to `192.0.2.0`, or a proxied `AAAA` record pointing to `100::` :::note `192.0.2.0` (A record) and `100::` (AAAA record) are [reserved placeholder addresses](/dns/manage-dns-records/how-to/create-dns-records/#originless-setups) for originless setups. Because the DNS record is proxied, requests never reach this address — Cloudflare intercepts them and applies your redirect rule. @@ -228,4 +230,4 @@ To migrate the route `example.com/*` in your [Wrangler configuration file](/work 4. Run `npx wrangler deploy` to create the Custom Domain your Worker will run on. - \ No newline at end of file + diff --git a/src/content/docs/workers/configuration/routing/workers-dev.mdx b/src/content/docs/workers/configuration/routing/workers-dev.mdx index 732cc8fa3a3..911a31b78a6 100644 --- a/src/content/docs/workers/configuration/routing/workers-dev.mdx +++ b/src/content/docs/workers/configuration/routing/workers-dev.mdx @@ -26,19 +26,13 @@ All Workers are assigned a `workers.dev` route when they are created or renamed ## Manage access to `workers.dev` -When enabled, your `workers.dev` URL is available publicly. You can use [Cloudflare Access](/cloudflare-one/access-controls/policies/) to require visitors to authenticate before accessing preview URLs. You can limit access to yourself, your teammates, your organization, or anyone else you specify in your [access policy](/cloudflare-one/access-controls/policies/). +When enabled, your `workers.dev` URL is available publicly. To require visitors to sign in before they can access a `workers.dev` URL, use [Cloudflare Access](/workers/configuration/cloudflare-access/). -To limit your `workers.dev` URL to authorized emails only: +Access can protect one Worker's production `workers.dev` URL, preview URLs, or both. You can also protect all Workers or all Worker previews in an account. -1. In the Cloudflare dashboard, go to the **Workers & Pages** page. - - +For defense in depth, [validate the Access JWT](/cloudflare-one/access-controls/applications/http-apps/authorization-cookie/validating-json/#cloudflare-workers-example) in your Worker code so unauthenticated requests cannot reach your application if Access is ever removed or misconfigured. -2. In **Overview**, select your Worker. -3. Go to **Settings** > **Domains & Routes**. -4. For `workers.dev`, click **Enable Cloudflare Access**. -5. Optionally, to configure the Access application, click **Manage Cloudflare Access**. There, you can change the email addresses you want to authorize. View [Access policies](/cloudflare-one/access-controls/policies/#selectors) to learn about configuring alternate rules. -6. [Validate the Access JWT](https://developers.cloudflare.com/cloudflare-one/access-controls/applications/http-apps/authorization-cookie/validating-json/#cloudflare-workers-example) in your Worker script using the audience (`aud`) tag and JWKs URL provided. +To use details about the signed-in user in your Worker, read the [user's identity](/cloudflare-one/access-controls/applications/http-apps/authorization-cookie/application-token/#user-identity) from the validated JWT or the `/cdn-cgi/access/get-identity` endpoint. ## Disabling `workers.dev` diff --git a/src/content/docs/workers/examples/basic-auth.mdx b/src/content/docs/workers/examples/basic-auth.mdx index 84e8be086b4..f820e4eabd3 100644 --- a/src/content/docs/workers/examples/basic-auth.mdx +++ b/src/content/docs/workers/examples/basic-auth.mdx @@ -28,7 +28,7 @@ This example Worker makes use of the [Node.js Buffer API](/workers/runtime-apis/ :::caution[Caution when using in production] -This code is provided as a sample, and is not suitable for production use. Basic Authentication sends credentials unencrypted, and must be used with an HTTPS connection to be considered secure. For a production-ready authentication system, consider using [Cloudflare Access](https://developers.cloudflare.com/cloudflare-one/access-controls/applications/http-apps/self-hosted-public-app/). +This code is provided as a sample, and is not suitable for production use. Basic Authentication sends credentials unencrypted, and must be used with an HTTPS connection to be considered secure. For a production-ready authentication system, consider using [Cloudflare Access](/workers/configuration/cloudflare-access/). ::: diff --git a/src/content/docs/workers/local-development/index.mdx b/src/content/docs/workers/local-development/index.mdx index fb15a69e76f..cf347a05314 100644 --- a/src/content/docs/workers/local-development/index.mdx +++ b/src/content/docs/workers/local-development/index.mdx @@ -301,7 +301,7 @@ There are two recommended patterns for this: ### Important Considerations -- **Cloudflare Access**: If your Worker is protected by [Cloudflare Access](/cloudflare-one/), Wrangler must authenticate with Access when connecting to remote bindings. Refer to [Connect to Access-protected Workers](#connect-to-access-protected-workers). +- **Cloudflare Access**: If your Worker is protected by [Cloudflare Access](/workers/configuration/cloudflare-access/), Wrangler must authenticate with Access when connecting to remote bindings. Refer to [Connect to Access-protected Workers](#connect-to-access-protected-workers). - **Data modification**: Operations (writes, deletes, updates) on bindings connected remotely will affect your actual data in the targeted Cloudflare resource (be it preview or production). @@ -311,7 +311,7 @@ There are two recommended patterns for this: ### Connect to Access-protected Workers -If your Worker is deployed behind a [Cloudflare Access](/cloudflare-one/) application — for example, if the `*.workers.dev` subdomain on your account is protected by Access, or if you have placed an Access policy on the custom route of the Worker — Wrangler must authenticate with Access when connecting to your remote bindings. +If your Worker is protected by [Cloudflare Access](/workers/configuration/cloudflare-access/), Wrangler must authenticate with Access when connecting to your remote bindings. This applies whether Access protects the Worker itself, all Workers in the account, a `workers.dev` hostname, a Custom Domain, or another hostname or path that routes to the Worker. There are two ways you can authenticate against Access: @@ -329,12 +329,12 @@ To set up service token authentication: 2. **Add a Service Auth policy to the Access application that protects your Worker.** - Open the _existing_ Access application that already covers the hostname of the Worker — typically the wildcard application for `*..workers.dev`, or the application that protects your custom domain — and attach a new policy with: + Open the _existing_ Access application that already protects the Worker or the hostname you use for remote bindings, and attach a new policy with: - **Action**: Service Auth - **Include**: The service token you created, or "Any Access Service Token" if you want to allow any service token to access the Worker. :::caution - Do not create a _separate_ Access application scoped only to the Worker's hostname. Doing so has been observed to block requests even when the existing wildcard application is left in place — refer to [opennextjs-cloudflare#1171](https://github.com/opennextjs/opennextjs-cloudflare/issues/1171). Attach the Service Auth policy to the existing application that already protects the hostname. + Do not create a separate Access application for the same Worker or hostname only to add service token authentication. Doing so can conflict with the Access application that already protects the Worker. Attach the Service Auth policy to the existing application instead. ::: 3. **Expose the credentials to Wrangler.** diff --git a/src/content/docs/workers/runtime-apis/cache.mdx b/src/content/docs/workers/runtime-apis/cache.mdx index 4e414b23473..a0a4d05acbc 100644 --- a/src/content/docs/workers/runtime-apis/cache.mdx +++ b/src/content/docs/workers/runtime-apis/cache.mdx @@ -22,7 +22,7 @@ The `cache.put` method is not compatible with tiered caching. Refer to [Cache AP Workers deployed to custom domains have access to functional `cache` operations. So do [Pages functions](/pages/functions/), whether attached to custom domains or `*.pages.dev` domains. -However, any Cache API operations in the Cloudflare Workers dashboard editor and [Playground](/workers/playground/) previews will have no impact. For Workers fronted by [Cloudflare Access](https://www.cloudflare.com/teams/access/), the Cache API is not currently available. +However, any Cache API operations in the Cloudflare Workers dashboard editor and [Playground](/workers/playground/) previews will have no impact. For Workers fronted by [Cloudflare Access](/workers/configuration/cloudflare-access/), the Cache API is not currently available. :::note diff --git a/src/content/docs/workers/static-assets/migration-guides/migrate-from-pages.mdx b/src/content/docs/workers/static-assets/migration-guides/migrate-from-pages.mdx index 41d3dfeee94..dad580dadf9 100644 --- a/src/content/docs/workers/static-assets/migration-guides/migrate-from-pages.mdx +++ b/src/content/docs/workers/static-assets/migration-guides/migrate-from-pages.mdx @@ -343,7 +343,7 @@ To get a similar experience in Workers, you must: 1. [Enable non-production branch builds](/workers/ci-cd/builds/build-branches/#configure-non-production-branch-builds) in Workers Builds. -Optionally, you can also [protect these preview URLs with Cloudflare Access](/workers/configuration/previews/#manage-access-to-preview-urls). +Optionally, you can also [protect these preview URLs with Cloudflare Access](/workers/configuration/cloudflare-access/). :::note