diff --git a/products/cloudflare-one/src/content/connections/connect-apps/install-and-setup/setup.md b/products/cloudflare-one/src/content/connections/connect-apps/install-and-setup/setup.md index a2eb2b784a0..e3afa63f7b5 100644 --- a/products/cloudflare-one/src/content/connections/connect-apps/install-and-setup/setup.md +++ b/products/cloudflare-one/src/content/connections/connect-apps/install-and-setup/setup.md @@ -1,6 +1,7 @@ --- order: 2 pcx-content-type: how-to +hidden: true --- # Authenticate `cloudflared` diff --git a/products/cloudflare-one/src/content/connections/connect-apps/install-and-setup/tunnel-guide.md b/products/cloudflare-one/src/content/connections/connect-apps/install-and-setup/tunnel-guide.md index 3a03d50175a..0d42d532ad7 100644 --- a/products/cloudflare-one/src/content/connections/connect-apps/install-and-setup/tunnel-guide.md +++ b/products/cloudflare-one/src/content/connections/connect-apps/install-and-setup/tunnel-guide.md @@ -6,7 +6,8 @@ pcx-content-type: how-to # Set up your first tunnel -Follow this step-by-step guide to getting your first tunnel up and running. Before you start, make sure you: +Follow this step-by-step guide to get your first tunnel up and running. Before you start, make sure you: + 1. [Add a website to Cloudflare](https://support.cloudflare.com/hc/en-us/articles/201720164-Creating-a-Cloudflare-account-and-adding-a-website) 1. [Change your domain nameservers to Cloudflare](https://support.cloudflare.com/hc/en-us/articles/205195708) diff --git a/products/cloudflare-one/src/content/connections/connect-apps/run-tunnel/deploy-cloudflared-replicas.md b/products/cloudflare-one/src/content/connections/connect-apps/run-tunnel/deploy-cloudflared-replicas.md index e4723ceffdb..a1aa1ffd8dc 100644 --- a/products/cloudflare-one/src/content/connections/connect-apps/run-tunnel/deploy-cloudflared-replicas.md +++ b/products/cloudflare-one/src/content/connections/connect-apps/run-tunnel/deploy-cloudflared-replicas.md @@ -13,13 +13,13 @@ To deploy multiple `cloudflared` replicas: 1. Run the following command: - ```sh + ```bash $ cloudflared tunnel create ``` 1. Next, run your newly created Named Tunnel. - ```sh + ```bash $ cloudflared tunnel run ``` @@ -27,7 +27,7 @@ To deploy multiple `cloudflared` replicas: 1. In a separate window, run the same command to initialize another `cloudflared` instance: - ```sh + ```bash $ cloudflared tunnel run ``` @@ -35,7 +35,7 @@ To deploy multiple `cloudflared` replicas: 1. Next, run `tunnel info` to show each `cloudflared` running your tunnel: - ```sh + ```bash $ cloudflared tunnel info ``` diff --git a/products/cloudflare-one/src/content/connections/connect-apps/tunnel-useful-terms.md b/products/cloudflare-one/src/content/connections/connect-apps/tunnel-useful-terms.md index 0023efa18c4..18d0eecbb37 100644 --- a/products/cloudflare-one/src/content/connections/connect-apps/tunnel-useful-terms.md +++ b/products/cloudflare-one/src/content/connections/connect-apps/tunnel-useful-terms.md @@ -15,13 +15,13 @@ A tunnel UUID is an alpha-numeric, unique ID assigned to a tunnel. The tunnel UU The `cloudflared tunnel create ` command creates a tunnel and assigns it a name. Once named, a tunnel is a persistent pathway within which you can stop and start as many [connectors](#connector) as needed, adding stability and ease of use to your tunnel experience. Tunnel names do not need to be hostnames; for example, you can assign your tunnel a name that represents your application/network, a particular server, or the cloud environment where it runs. A human-readable identifier lets you easily reference a tunnel whenever you need. ## Connector -Users can create and configure a tunnel once and run it as multiple different `cloudflared` processes. These processes are known as connectors, or replicas. DNS records and Cloudflare Load Balancers can still point to the tunnel and its UUID, while that tunnel sends traffic to the multiple instances of cloudflared that run through it. Using multiple connectors provides tunnels with high availability, scalability, and elasticity. +Users can create and configure a tunnel once and run it as multiple different `cloudflared` processes. These processes are known as connectors. DNS records and Cloudflare Load Balancers can still point to the tunnel and its UUID, while that tunnel sends traffic to the multiple instances of cloudflared that run through it. Using multiple connectors provides tunnels with high availability, scalability, and elasticity. ## Configuration file This is a `.yaml` file that functions as the operating manual for `cloudflared`. By creating a configuration file, you can have fine-grained control over how their instance of cloudflared will operate. This includes operations like what you want `cloudflared` to do with traffic (for example, proxy websockets to port `xxxx`, or ssh to port `yyyy`), where `cloudflared` should search for authorization (credentials file, tunnel token), and what mode it should run in (for example, [`warp-routing`](/connections/connect-networks/private-net/create-tunnel#configure-the-tunnel)). In the absence of a configuration file, cloudflared will proxy outbound traffic through port `8080`. ## Cert.pem -This is the certificate file issued by Cloudflare when you run `cloudflared tunnel login`. This file is required when you create new tunnels, delete existing tunnels, change DNS records, or configure tunnel routing from cloudflared. This file is not required to perform actions such as running an existing tunnel or managing tunnel routing from the Cloudflare dashboard. The cert.pem origin certificate is valid for at least 10 years, and the service token it contains is valid until revoked. +This is the certificate file issued by Cloudflare when you run `cloudflared tunnel login`. This file uses a certificate to authenticate your instance of `cloudflared` and it is required when you create new tunnels, delete existing tunnels, change DNS records, or configure tunnel routing from cloudflared. This file is not required to perform actions such as running an existing tunnel or managing tunnel routing from the Cloudflare dashboard. The cert.pem origin certificate is valid for at least 10 years, and the service token it contains is valid until revoked. ## Credentials file This file is created when you run `cloudflared tunnel create `. It stores your tunnel’s credentials in a `.json` format, and is unique to each tunnel. This file functions as a token authenticating the tunnel it is associated with. diff --git a/products/cloudflare-one/src/content/connections/connect-networks/private-net/create-tunnel/index.md b/products/cloudflare-one/src/content/connections/connect-networks/private-net/create-tunnel/index.md index 0c25a43774b..cef9f70962a 100644 --- a/products/cloudflare-one/src/content/connections/connect-networks/private-net/create-tunnel/index.md +++ b/products/cloudflare-one/src/content/connections/connect-networks/private-net/create-tunnel/index.md @@ -13,8 +13,8 @@ pcx-content-type: how-to To create a Tunnel, run the following command: -```sh -cloudflared tunnel create +```bash +$ cloudflared tunnel create ``` Replace `` with the name you want to give to the Tunnel. The name assigned can be any string and does not need to relate to a hostname or your account name. @@ -31,8 +31,8 @@ You can also view and manage the Tunnels generated. Click [here](/connections/co To map the Tunnel to a range of IPs, run the following command: -```sh -cloudflared tunnel route ip add +```bash +$ cloudflared tunnel route ip add ``` Replace `` with the range of IPs that this Tunnel represents, for example `10.1.2.40/29`. The IP addresses used can include RFC 1918 ranges. The `` value should be the name of a Tunnel already created. @@ -44,7 +44,7 @@ This command will tell Cloudflare to send traffic from users in your organizatio Confirm the routes enrolled with the following command: ```bash -cloudflared tunnel route ip show +$ cloudflared tunnel route ip show ``` ![IP List](../../../../static/secure-origin-connections/warp-to-tunnel/ip-list.png) @@ -52,7 +52,7 @@ cloudflared tunnel route ip show You can test the routing configuration with the following command as well: ```bash -cloudflared tunnel route ip get 100.64.0.1 +$ cloudflared tunnel route ip get 100.64.0.1 ``` ## Configure the Tunnel diff --git a/products/cloudflare-one/src/content/faq/teams-policies-faq.md b/products/cloudflare-one/src/content/faq/teams-policies-faq.md index 3d1286e78a2..c12f3a8b9e0 100644 --- a/products/cloudflare-one/src/content/faq/teams-policies-faq.md +++ b/products/cloudflare-one/src/content/faq/teams-policies-faq.md @@ -20,7 +20,7 @@ Wildcard-based policies in Cloudflare Access only cover the level where they are ## Can I use regular expressions to build policies? -You can use wildcards when setting up Zero Trust policies. Wildcards are useful when specifying application paths you want to protect. For more information, see our guide for [Using wildcards in subdomains and path](/applications/configure-apps/app-paths#using-wildcards-in-subdomains-and-paths). +You can use wildcards when setting up Zero Trust policies. Wildcards are useful when specifying application paths you want to protect. For more information, see our guide for [Using wildcards in subdomains and path](/policies/zero-trust/app-paths#using-wildcards-in-subdomains-and-paths). Gateway uses Rust to evaluate regular expressions. The Rust implementation is slightly different than regex libraries used elsewhere. For example, if you want to match multiple domains, you could use the pipe symbol (`|`) as an OR operator. In Gateway, you do not need to use an escape character (`\`) before the pipe symbol. Let's say you want to block requests to two hosts if either appears in a request header. A regex for such a rule would look like this: diff --git a/products/cloudflare-one/src/content/identity/idp-integration/adfs.md b/products/cloudflare-one/src/content/identity/idp-integration/adfs.md index fd57513b7f3..127a37bbabf 100644 --- a/products/cloudflare-one/src/content/identity/idp-integration/adfs.md +++ b/products/cloudflare-one/src/content/identity/idp-integration/adfs.md @@ -114,10 +114,7 @@ The **Edit Claim Rules for CF Login** screen automatically displays. Now create 2 Claim Rules so that ADFS can take information from Cloudflare and return it to create [Zero Trust policies](/policies/zero-trust). - +If you closed the Add Relying Trust wizard, use Explorer to find the **Relying Party Trusts** folder, select the newly created RPT file, and click **Edit Claim Rules** in the **Action** sidebar. To create Claim Rules: diff --git a/products/cloudflare-one/src/content/identity/idp-integration/citrixadc-saml.md b/products/cloudflare-one/src/content/identity/idp-integration/citrixadc-saml.md index 7d49469c10e..a55e472d18d 100644 --- a/products/cloudflare-one/src/content/identity/idp-integration/citrixadc-saml.md +++ b/products/cloudflare-one/src/content/identity/idp-integration/citrixadc-saml.md @@ -12,13 +12,7 @@ Cloudflare for Teams can integrate with Citrix ADC (formerly Citrix NetScaler AD To set up Citrix ADC (SAML) as your identity provider: 1. First, you'll need to configure 2 SAML certificates: - * A certificate to **terminate TLS at the vServer**. - - - + * A certificate to **terminate TLS at the vServer**. Ensure that the certificate is issued by a publicly trusted CA. * A certificate for **signing SAML assertions**. If you do not already have a certificate for signing SAML assertions, you can use a self-signed certificate generated on Citrix ADC by following these steps: diff --git a/products/cloudflare-one/src/content/identity/idp-integration/github.md b/products/cloudflare-one/src/content/identity/idp-integration/github.md index 83e2ed1cc77..7947aa83865 100644 --- a/products/cloudflare-one/src/content/identity/idp-integration/github.md +++ b/products/cloudflare-one/src/content/identity/idp-integration/github.md @@ -48,11 +48,8 @@ To configure GitHub access in both GitHub and Cloudflare for Teams: 1. Click **Save**. -To test that your connection is working, navigate to **Authentication > Login methods** and click **Test** next to GitHub. - - ## Example API Configuration diff --git a/products/cloudflare-one/src/content/identity/idp-integration/google.md b/products/cloudflare-one/src/content/identity/idp-integration/google.md index 10779216645..3fbb5f10162 100644 --- a/products/cloudflare-one/src/content/identity/idp-integration/google.md +++ b/products/cloudflare-one/src/content/identity/idp-integration/google.md @@ -5,14 +5,10 @@ pcx-content-type: how-to # Google - - You can integrate Google authentication with Cloudflare Access without a Google Workspace account. The integration will allow any user with a Google account to login (if the [Zero Trust policy](/policies/zero-trust) allows them to reach the resource). Unlike the instructions for [Google Workspace](/identity/idp-integration/gsuite), the steps below will not allow you to pull group membership information from a Google Workspace account. +Please note that you don't need to be a Google Cloud Platform user to integrate Google Suite as an identity provider with Cloudflare for Teams. You will only need to open the Google Cloud Platform to access settings for your OIDC identity provider. + 1. Visit the Google Cloud Platform console. Create a new project. ![Create Project](../../static/documentation/identity/google/create-project.png) diff --git a/products/cloudflare-one/src/content/identity/idp-integration/gsuite.md b/products/cloudflare-one/src/content/identity/idp-integration/gsuite.md index edc4cffad6a..95f44975b4a 100644 --- a/products/cloudflare-one/src/content/identity/idp-integration/gsuite.md +++ b/products/cloudflare-one/src/content/identity/idp-integration/gsuite.md @@ -5,16 +5,12 @@ pcx-content-type: how-to # Google Workspace - - You can integrate a Google Workspace (formerly Google Suite) account with Cloudflare Access. Unlike the instructions for [generic Google authentication](/identity/idp-integration/google), the steps below will allow you to pull group membership information from your Google Workspace account. Once integrated, users will login with their Google Workspace credentials to reach resources protected by Cloudflare Access or to enroll their device into Cloudflare Gateway. +Please note that you don't need to be a Google Cloud Platform user to integrate Google Suite as an identity provider with Cloudflare for Teams. You will only need to open the Google Cloud Platform to access settings for your OIDC identity provider. + 1. Log into the Google Cloud Platform [console](https://console.cloud.google.com/). This is separate from your Google Workspace console. ![GCP Console](../../static/documentation/identity/gsuite/gcp-home.png) diff --git a/products/cloudflare-one/src/content/identity/idp-integration/onelogin-saml.md b/products/cloudflare-one/src/content/identity/idp-integration/onelogin-saml.md index fbdc7f71a65..85bf63ed268 100644 --- a/products/cloudflare-one/src/content/identity/idp-integration/onelogin-saml.md +++ b/products/cloudflare-one/src/content/identity/idp-integration/onelogin-saml.md @@ -56,15 +56,10 @@ To set up OneLogin (SAML) as your identity provider: 1. Select SAML. -1. Input the details from your OneLogin account in the fields. +1. Input the details from your OneLogin account in the fields. We suggest that you name the attributes the same in both OneLogin and Cloudflare. If other headers and SAML attribute names were added to OneLogin, be sure to add them to Cloudflare under **SAML attributes** and **SAML header attributes** in the **Optional configurations** menu. - - 1. Click **Save**. To test that your connection is working, navigate to **Authentication > Login methods** and click **Test** next to the login method you want to test. diff --git a/products/cloudflare-one/src/content/identity/idp-integration/signed_authn.md b/products/cloudflare-one/src/content/identity/idp-integration/signed_authn.md index e565f2f595d..45fcd3ec315 100644 --- a/products/cloudflare-one/src/content/identity/idp-integration/signed_authn.md +++ b/products/cloudflare-one/src/content/identity/idp-integration/signed_authn.md @@ -29,11 +29,8 @@ To set up Signed AuthN requests: https://.cloudflareaccess.com/cdn-cgi/access/public-cert ``` - - Cloudflare Access uses a certificate that includes the following 2 distinguished name fields: * **Issuer Distinguished Name** – `CN=cloudflareaccess.com, C=US, ST=Texas, L=Austin, O=Cloudflare` diff --git a/products/cloudflare-one/src/content/policies/filtering/applications-changelog.md b/products/cloudflare-one/src/content/policies/filtering/applications-changelog.md index 2d1a80c666b..1cbcc7ceee5 100644 --- a/products/cloudflare-one/src/content/policies/filtering/applications-changelog.md +++ b/products/cloudflare-one/src/content/policies/filtering/applications-changelog.md @@ -1,6 +1,7 @@ --- order: 10 pcx-content-type: reference +hidden: true --- # Applications changelog diff --git a/products/cloudflare-one/src/content/policies/filtering/dns-policies/index.md b/products/cloudflare-one/src/content/policies/filtering/dns-policies/index.md index eaa556004c0..fb751895a85 100644 --- a/products/cloudflare-one/src/content/policies/filtering/dns-policies/index.md +++ b/products/cloudflare-one/src/content/policies/filtering/dns-policies/index.md @@ -1,6 +1,7 @@ --- order: 2 pcx-content-type: concept +hidden: true --- # DNS policies diff --git a/products/cloudflare-one/src/content/policies/filtering/http-policies/tenant-control.md b/products/cloudflare-one/src/content/policies/filtering/http-policies/tenant-control.md index 4da7155c030..a9dc209a8d3 100644 --- a/products/cloudflare-one/src/content/policies/filtering/http-policies/tenant-control.md +++ b/products/cloudflare-one/src/content/policies/filtering/http-policies/tenant-control.md @@ -39,26 +39,52 @@ Your Allow policy is now displayed in the list of HTTP rules. When an end user a This section covers policy configurations for common SaaS applications. -## Dropbox +### Microsoft 365 + + | Selector | Operator | Value | Action | Header name | | -- | -- | -- | -- | -- | -| Application | In | Dropbox | Allow | `X-Dropbox-allowed-Team-Ids` | +| Application | In | Microsoft Office365 | Allow | `Restrict-Access-To-Tenants`, `Restrict-Access-Context` | + + + +### Slack + + + +| Selector | Operator | Value | Action | Header name | +| -- | -- | -- | -- | -- | +| Application | In | Slack | Allow | `X-Slack-Allowed-Workspaces-Requester`, `X-Slack-Allowed-Workspaces` | -## G Suite + + +### G Suite + + | Selector | Operator | Value | Action | Header name | | -- | -- | -- | -- | -- | | Application | In | Google Workspace | Allow | `X-GooGApps-Allowed-Domains` | -## Microsoft 365 + + +### Dropbox + + | Selector | Operator | Value | Action | Header name | | -- | -- | -- | -- | -- | -| Application | In | Microsoft Office365 | Allow | `Restrict-Access-To-Tenants`, `Restrict-Access-Context` | +| Application | In | Dropbox | Allow | `X-Dropbox-allowed-Team-Ids` | + + -## YouTube +### YouTube + + | Selector | Operator | Value | Action | Header name | | -- | -- | -- | -- | -- | | Application | In | YouTube | Allow | `YouTube-Restrict` | + + \ No newline at end of file diff --git a/products/cloudflare-one/src/content/static/documentation/connections/proxy.png b/products/cloudflare-one/src/content/static/documentation/connections/proxy.png new file mode 100644 index 00000000000..7cfba72daff Binary files /dev/null and b/products/cloudflare-one/src/content/static/documentation/connections/proxy.png differ diff --git a/products/cloudflare-one/src/content/tutorials/block-tld.md b/products/cloudflare-one/src/content/tutorials/block-tld.md index 4dfaa3a6be3..169eb5ddfa1 100644 --- a/products/cloudflare-one/src/content/tutorials/block-tld.md +++ b/products/cloudflare-one/src/content/tutorials/block-tld.md @@ -28,7 +28,7 @@ Visit the Cloudflare for Teams dashboard. Open the `Policies` page in the Gatewa Click **Create a policy**. In the policy builder, name the policy and optionally provide a description. -Choose `DNS Domain` in the Selector, `matches regex`, in the Operator, and input the following value: +Choose `Domain` in the Selector, `matches regex` in the Operator, and input the following value: ``` [.]fail @@ -46,6 +46,12 @@ Finish the policy by clicking **Create policy**. Input the TLD you need to block. If you need to block `.fail` remove the leading `.` and only input `fail`. Click **Add to policy** and save the policy. + + ## Review logs You can test your policy by attempting to visit a domain with the blocked TLD. To review logs of the block, navigate to the `Logs` section of the Cloudflare for Teams dashboard, select `Gateway`, and choose the `DNS` tab. diff --git a/products/cloudflare-one/src/content/tutorials/do-not-decrypt.md b/products/cloudflare-one/src/content/tutorials/do-not-decrypt.md index b6f0ef500cf..2807dc95cb7 100644 --- a/products/cloudflare-one/src/content/tutorials/do-not-decrypt.md +++ b/products/cloudflare-one/src/content/tutorials/do-not-decrypt.md @@ -11,7 +11,7 @@ You can configure Cloudflare for Teams to skip inspection for certain groups of By default, Cloudflare Gateway creates a rule that includes the hostnames used by certain client applications, like Zoom or Apple's services, that rely on certificate pinning. The TLS inspection performed by a service like Cloudflare Gatway will cause errors when users visit those applications. -This tutorial skips inspection for additional appilcations beyond those in the list curated by Cloudflare. +This tutorial skips inspection for additional applications beyond those in the list curated by Cloudflare. **🗺️ This walkthrough covers how to:** diff --git a/products/cloudflare-one/src/content/tutorials/secure-dns-network.md b/products/cloudflare-one/src/content/tutorials/secure-dns-network.md index 80381476edf..466cd48202e 100755 --- a/products/cloudflare-one/src/content/tutorials/secure-dns-network.md +++ b/products/cloudflare-one/src/content/tutorials/secure-dns-network.md @@ -77,6 +77,6 @@ The default toggle presented will be `Router`. Follow the instructions on the pa ## Review events -Once configured, you can review DNS queries made from your network in the Gateway overview page. +Once configured, you can review DNS queries made from your network in the **Analytics** > **Gateway** page. -![Gateway Overview](../static/secure-web-gateway/secure-dns-network/gateway-overview.png) \ No newline at end of file +![Gateway Analytics](../static/secure-web-gateway/secure-dns-network/gateway-analytics.png) \ No newline at end of file diff --git a/products/magic-transit/src/content/about/probe-construction.md b/products/magic-transit/src/content/about/probe-construction.md index eb0f9685938..f4841cf1db9 100644 --- a/products/magic-transit/src/content/about/probe-construction.md +++ b/products/magic-transit/src/content/about/probe-construction.md @@ -59,6 +59,10 @@ The values for failure penalties are intentionally extreme so that they always e Applying a penalty instead of removing the route altogether preserves redundancy and maintains options for customers with only one tunnel. Penalties also support the case when multiple tunnels are unhealthy. +### Cloudflare data centers and tunnels + +In the event a Cloudflare data center is down, Cloudflare's edge network does not advertise your prefixes, and your packets are routed to the next closest data center. To check the system status for Cloudflare's edge network and dashboard, refer to [Cloudflare System Status](https://www.cloudflarestatus.com/). + ## Recovery Once a tunnel is in the **Down** state, edge servers continue to emit probes every 60 seconds. When a probe returns **Healthy**, the edge server that received the healthy packet immediately sends two more probes. If the two probes return **Healthy**, Magic Transit sets the tunnel status to **Degraded**. diff --git a/products/magic-wan/src/content/get-started/configure-tunnels/assign-tunnel-priorities.md b/products/magic-wan/src/content/get-started/configure-tunnels/assign-tunnel-priorities.md index bd90fc769c0..9d8d1bb3f9f 100644 --- a/products/magic-wan/src/content/get-started/configure-tunnels/assign-tunnel-priorities.md +++ b/products/magic-wan/src/content/get-started/configure-tunnels/assign-tunnel-priorities.md @@ -1,6 +1,6 @@ --- -title: Assign tunel properties -order: 5 +title: Create static routes +order: pcx-content-type: how-to --- diff --git a/products/magic-wan/src/content/get-started/configure-tunnels/map-route-prefixes.md b/products/magic-wan/src/content/get-started/configure-tunnels/map-route-prefixes.md deleted file mode 100644 index 9fe96bf1e76..00000000000 --- a/products/magic-wan/src/content/get-started/configure-tunnels/map-route-prefixes.md +++ /dev/null @@ -1,18 +0,0 @@ ---- -title: Map route prefixes -order: 6 -pcx-content-type: how-to ---- - -# Map route prefixes smaller than /24 - -Before Cloudflare can route your traffic from the edge to your locations via GRE tunnels, you must provide your prefixes and the tunnels to which they should be mapped, similar to the example in the table below. - -| Prefix | GRE Tunnel | -| --------------- | ---------- | -| 103.21.244.0/29 | GRE_1_IAD | -| 103.21.244.8/29 | GRE_2_ATL | - -The minimum advertising prefix is /24. However, because Cloudflare uses GRE tunnels as an outer wrapper for your traffic, Cloudflare can route prefixes within that /24 to different tunnel endpoints. - -For example, you can send `x.x.x.0/29` to Datacenter 1 and `x.x.x.8/29` to Datacenter 2, which is helpful when operating in environments with constrained IP resources. \ No newline at end of file diff --git a/products/magic-wan/src/content/get-started/configure-tunnels/specify-ip-addresses.md b/products/magic-wan/src/content/get-started/configure-tunnels/specify-ip-addresses.md index 8c082808aec..d3ee12586a8 100644 --- a/products/magic-wan/src/content/get-started/configure-tunnels/specify-ip-addresses.md +++ b/products/magic-wan/src/content/get-started/configure-tunnels/specify-ip-addresses.md @@ -1,6 +1,6 @@ --- title: Specify IP address for endpoint health checks -order: 7 +order: pcx-content-type: how-to --- diff --git a/products/magic-wan/src/content/get-started/configure-tunnels/specify-tunnel-endpoints.md b/products/magic-wan/src/content/get-started/configure-tunnels/specify-tunnel-endpoints.md index 5c5beceb811..a38072fa13c 100644 --- a/products/magic-wan/src/content/get-started/configure-tunnels/specify-tunnel-endpoints.md +++ b/products/magic-wan/src/content/get-started/configure-tunnels/specify-tunnel-endpoints.md @@ -1,6 +1,6 @@ --- title: Specify tunnel endpoints -order: 4 +order: pcx-content-type: how-to --- diff --git a/products/magic-wan/src/content/reference/configuration-examples.md b/products/magic-wan/src/content/reference/configuration-examples.md index 34ddda84b6c..fd7a1334adc 100644 --- a/products/magic-wan/src/content/reference/configuration-examples.md +++ b/products/magic-wan/src/content/reference/configuration-examples.md @@ -1,5 +1,5 @@ --- -order: 9 +order: pcx-content-type: reference --- diff --git a/products/magic-wan/src/content/reference/index.md b/products/magic-wan/src/content/reference/index.md index 94b2c2df818..6dd24c0a4e3 100644 --- a/products/magic-wan/src/content/reference/index.md +++ b/products/magic-wan/src/content/reference/index.md @@ -1,5 +1,5 @@ --- -order: 8 +order: pcx-content-type: navigation --- diff --git a/products/stream/src/content/viewing-videos/securing-your-stream.md b/products/stream/src/content/viewing-videos/securing-your-stream.md index 96af9393afa..c4f888df03b 100644 --- a/products/stream/src/content/viewing-videos/securing-your-stream.md +++ b/products/stream/src/content/viewing-videos/securing-your-stream.md @@ -59,6 +59,7 @@ You can call the `/token` endpoint for any video that is marked private to get a ```bash curl \ +-X POST \ -H "Authorization: Bearer $TOKEN" \ https://api.cloudflare.com/client/v4/accounts/$ACCOUNT/stream/$VIDEOID/token ``` diff --git a/products/warp-client/src/content/index.md b/products/warp-client/src/content/index.md index 9a84931aaa6..55682fb5aae 100644 --- a/products/warp-client/src/content/index.md +++ b/products/warp-client/src/content/index.md @@ -17,7 +17,7 @@ The Cloudflare WARP client allows individuals and organizations to have a faster * **1.1.1.1 with WARP** * **WARP via Local Proxy** * **WARP+** -* **WARP Unilimited** +* **WARP Unlimited** Scroll down for a description of each mode. diff --git a/products/workers/src/content/examples/multiple-cron-triggers.md b/products/workers/src/content/examples/multiple-cron-triggers.md new file mode 100644 index 00000000000..ceedadfc124 --- /dev/null +++ b/products/workers/src/content/examples/multiple-cron-triggers.md @@ -0,0 +1,40 @@ +--- +order: 1000 +type: example +summary: Set multiple Cron Triggers on three different schedules. +tags: + - Middleware +pcx-content-type: configuration +--- + +# Multiple Cron Triggers + + +

{props.frontmatter.summary}

+ + +```js +addEventListener('scheduled', event => { + event.waitUntil(triggerEvent(event.cron)) +}) + +async function triggerEvent(event.cron) { + // Write code for updating your API + switch (event.cron) { + // You can set up to three schedules maximum. + case "*/3 * * * *": + // Every three minutes + await updateAPI(); + break; + case "*/10 * * * *": + // Every ten minutes + await updateAPI2(); + break; + case "*/45 * * * *": + // Every forty-five minutes + await updateAPI3(); + break; + } + console.log("cron processed") +} +``` diff --git a/products/workers/src/content/tutorials/authorize-users-with-auth0/index.md b/products/workers/src/content/tutorials/authorize-users-with-auth0/index.md index b8efae1055b..492b10625a8 100644 --- a/products/workers/src/content/tutorials/authorize-users-with-auth0/index.md +++ b/products/workers/src/content/tutorials/authorize-users-with-auth0/index.md @@ -13,9 +13,9 @@ import TutorialsBeforeYouStart from "../../_partials/_tutorials-before-you-start ## Overview -In this tutorial you’ll integrate [Auth0](https://auth0.com), an identity management platform, into a Cloudflare Workers application. Adding authorization and authentication to an application is a common task for developers. By implementing it using Cloudflare Workers, you can take advantage of Workers’ unique platform advantages to simplify how and when your application needs user data. +In this tutorial you will integrate [Auth0](https://auth0.com), an identity management platform, into a Cloudflare Workers application. Adding authorization and authentication to an application is a common task for developers. By implementing it using Cloudflare Workers, you can take advantage of the Workers platform to simplify how and when your application needs user data. -### What you’ll learn +### What you will learn - How to authorize and authenticate users in Workers. - How to persist authorization credentials inside of Workers KV. @@ -23,19 +23,19 @@ In this tutorial you’ll integrate [Auth0](https://auth0.com), an identity mana ## Set up Auth0 -If you don’t already have an Auth0 account, you can sign up for a free account at [auth0.com](https://www.auth0.com). This tutorial supports integration with Auth0’s free tier. +If you do not already have an Auth0 account, sign up for a free account at [auth0.com](https://www.auth0.com). This tutorial supports integration with Auth0’s free tier. ### Configure an Auth0 application -Every Auth0 account contains _applications_, which allow developers to create login/signup flows that are verified by Auth0. Integrating Auth0 with Workers requires creating an application in your Auth0 dashboard; if you’ve created an account for this tutorial, the “Default (Generic)” application provided by Auth0 will work; otherwise, create a new application with the type “Regular Web Application”. +Every Auth0 account contains applications, which allow developers to create login/signup flows that are verified by Auth0. To integrate Auth0 with Workers, create an application in your Auth0 dashboard. If you have created an account for this tutorial, the **Default (Generic)** application provided by Auth0 will work; otherwise, create a new application with the type **Regular Web Application**. ![Creating an Auth0 application](./media/creating-an-application.png) -Inside of our application’s settings, the client ID and client secret are keys that we’ll provide to our Workers application to authenticate with Auth0. There are several settings and configuration options here, but relevant to this tutorial are the “Allowed Callback URLs” and “Allowed Web Origins” options. In the “Publish” section of this tutorial, we’ll fill in these values with the final deployed URL of our application. +Inside of your application’s settings, the client ID and client secret are keys that you will provide to your Workers application to authenticate with Auth0. There are several settings and configuration options, but relevant to this tutorial are the **Allowed Callback URLs** and **Allowed Web Origins** options. In the [**Publish** section](/authorize-users-with-auth0#publish) of this tutorial, you will later fill in these values with the final deployed URL of our application. ## Generate a new project -Using wrangler’s `generate` command, we can begin building a new application using a Workers template. For this tutorial, we’ll heavily modify the default template for [Workers Sites](/platform/sites), which deploys a static HTML application: +Using wrangler’s `generate` command, begin building a new application using a Workers template. For this tutorial you will modify the default template for [Workers Sites](/platform/sites), which deploys a static HTML application: ```sh --- @@ -46,14 +46,14 @@ $ wrangler generate --site my-auth-example ## Building an authorizer -Before we begin implementing an “authorizer” in our application, which will verify that a user is logged in, it’s useful to understand how Auth0’s login flow works. The condensed version of this flow is below (and, if you’re interested, you can [read a longer writeup in Auth0’s docs](https://auth0.com/docs/flows/concepts/auth-code)): +Before implementing an “authorizer" in your application, which will verify that a user is logged in, it is useful to understand how Auth0’s login flow works. The condensed version of this flow is below (you can also [review a longer writeup in Auth0’s docs](https://auth0.com/docs/flows/concepts/auth-code)): -1. A user makes a request to the Workers application -2. If they aren’t logged in, they’re redirected to the login page -3. After logging in they’re redirected back to the Workers application, passing a login `code` as a query param -4. The Workers application takes the login `code` parameter and exchanges it with Auth0 for authorization tokens +1. A user makes a request to the Workers application. +2. If the user is not logged in, they are redirected to the login page. +3. After logging in, the user is redirected back to the Workers application with a login `code` query parameter. +4. The Workers application takes the login `code` parameter and exchanges it with Auth0 for authorization tokens. -In a traditional application that is attached to a database, the authorization tokens returned from Auth0 are often persisted in a database, allowing users to return to the application and continue to use it, without the need for re-authorization. With a Workers application, we have a quick and easy-to-use data storage solution that lives right next to our serverless application: Workers KV. Using Workers KV, we’ll store authorization tokens and tie them to a user using an authorization cookie. +In a traditional application that is attached to a database, the authorization tokens Auth0 returns are often persisted in a database. This will allow users to return to the application and continue to use it without the need for re-authorization. With a Workers application, you have access to a quick and easy-to-use data storage solution that lives right next to your serverless application: Workers KV. Using Workers KV, you will store authorization tokens and tie them to a user using an authorization cookie. [![Auth0 Flow](./media/auth0-flow.png)](https://auth0.com/docs/flows/concepts/auth-code) @@ -61,7 +61,7 @@ In a traditional application that is attached to a database, the authorization t ### Authenticating a user -Let’s begin implementing the login flow described in the previous section. When a user makes a request to the Workers application, we should verify that the user is authenticated. To define this logic create a new file — `workers-site/auth0.js`- which will contain the authorization logic for our application: +Begin implementing the login flow described in the previous section. When a user makes a request to the Workers application, you should verify that the user is authenticated. To define this logic create a new file — `workers-site/auth0.js`- which will contain the authorization logic for our application: ```js --- @@ -96,15 +96,15 @@ export const authorize = async event => { } ``` -The `auth0` object wraps several secrets, which are encrypted values that can be defined and used by your script. In the “Publish” section of this tutorial, we’ll define these secrets using the [`wrangler secret`](/cli-wrangler/commands#secret) command. +The `auth0` object wraps several secrets, which are encrypted values that can be defined and used by your script. In the [**Publish** section](/authorize-users-with-auth0#publish) of this tutorial, you will define these secrets using the [`wrangler secret`](/cli-wrangler/commands#secret) command. -The `generateStateParam` function will be used to prevent [Cross-Site Request Forgery attacks](https://auth0.com/docs/protocols/oauth2/mitigate-csrf-attacks). For now, we’ll return a string “stub”, but later in the tutorial, it will generate a random “state” parameter that we’ll store in Workers KV to verify incoming authorization requests. +The `generateStateParam` function will be used to prevent [Cross-Site Request Forgery attacks](https://auth0.com/docs/protocols/oauth2/mitigate-csrf-attacks). For now, you will return a string “stub” but later in the tutorial, `generateStateParam` will generate a random “state” parameter that you will store in Workers KV to verify incoming authorization requests. -The `verify` function, which we’ll stub out in our first pass through this file, will check for an authorization key and look up a corresponding value in Workers KV. For now, we’ll simply return an object with an `accessToken` string, to simulate an _authorized_ request. +The `verify` function, which you will stub out in your first pass through this file, will check for an authorization key and look up a corresponding value in Workers KV. For now, you will simply return an object with an `accessToken` string to simulate an authorized request. The `authorize` function, which should be exported from `./auth0.js`, will wait for the response from the `verify` function, and return an array that can be used to determine how the application should proceed. -In `workers-site/index.js`, we can import the `authorize` function from `./auth0.js` and use it inside of our `handleEvent` function. Note that by default the Workers Sites template contains code for rendering our Workers Site from Workers KV. To keep that code functioning, make sure that you replace `handleEvent` as defined below: +In `workers-site/index.js`, import the `authorize` function from `./auth0.js` and use it inside of your `handleEvent` function. Note that by default the Workers Sites template contains code for rendering our Workers Site from Workers KV. To keep that code functioning, make sure that you replace `handleEvent` as defined below: ```js --- @@ -124,7 +124,7 @@ async function handleEvent(event) { const [authorized, { authorization, redirectUrl }] = await authorize(event) // BEGINNING OF WORKERS SITES - // Make sure to not touch this code for the majority of the tutorial! + // Make sure to not touch this code for the majority of the tutorial. response = getAssetFromKV(event) // END OF WORKERS SITES @@ -137,7 +137,7 @@ async function handleEvent(event) { The `authorize` function returns an array with a boolean `authorized` and a context object which will contain either an `authorization` object or a `redirectUrl`. -Building on the past code sample, we can check that a user is `authorized` and that the `authorization` object contains an `accessToken`. Then update the incoming `request` to contain an `Authorization` header: +Building on the past code sample, you can check that a user is `authorized` and that the `authorization` object contains an `accessToken`. Then update the incoming `request` to contain an `Authorization` header: ```js --- @@ -161,7 +161,7 @@ async function handleEvent(event) { } ``` -If a user isn’t authorized, we can redirect them to Auth0’s login page, by calling `Response.redirect`, passing in the `redirectUrl`: +If a user is not authorized, redirect them to Auth0’s login page by calling `Response.redirect` and passing in the `redirectUrl`: ```js --- @@ -184,15 +184,15 @@ async function handleEvent(event) { } ``` -When a user logs in via Auth0’s login form, they’ll be redirected back to the callback URL specified by our application. In the next section, we’ll handle that redirect, and get a user access token as part of the “login” code flow. +When a user logs in via Auth0’s login form, they will be redirected back to the callback URL specified by our application. In the next section, you will handle that redirect and get a user access token as part of the "login" code flow. ![Auth0 Login Form](./media/auth0-login.png) ### Handling a login redirect -To handle the “login” code flow as defined by Auth0, we’ll handle an incoming request to the `/auth` path, which will contain a `code` parameter. By making another API request to Auth0, providing our app’s client ID and secret, we can exchange the login code for an access token. +To handle the “login” code flow as defined by Auth0, you will handle an incoming request to the `/auth` path, which will contain a `code` parameter. By making another API request to Auth0, providing our applications’s client ID and secret, you can exchange the login code for an access token. -To begin, we’ll add a new block of code to `handleEvent`, which will parse the request URL, and if the URL path matches `/auth`, we’ll call the newly imported `handleRedirect` function from `./auth0`. +To begin, add a new block of code to `handleEvent`, which will parse the request URL, and if the URL path matches `/auth`, call the newly imported `handleRedirect` function from `./auth0`. ```js --- @@ -214,7 +214,7 @@ async function handleEvent(event) { } ``` -The `handleRedirect` function, which we’ll export from `workers-site/auth0.js`, will parse the incoming URL, and pass the `code` login parameter to `exchangeCode`. We’ll also check for a `state` parameter, which we’ll use to prevent CSRF attacks. This `state` parameter should be matched to a known key in KV, indicating that the authorization request is valid: +The `handleRedirect` function, which you will export from `workers-site/auth0.js`, will parse the incoming URL, and pass the `code` login parameter to `exchangeCode`. Check for a `state` parameter, which you will use to prevent CSRF attacks. This `state` parameter should be matched to a known key in KV, indicating that the authorization request is valid: ```js --- @@ -241,7 +241,7 @@ export const handleRedirect = async event => { } ``` -Let’s define `exchangeCode`, which will take the `code` parameter, and make a request back to Auth0, exchanging it for an access token: +Define `exchangeCode`, which will take the `code` parameter, and make a request back to Auth0, exchanging it for an access token: ```js --- @@ -269,7 +269,7 @@ const exchangeCode = async code => { ### Persisting authorization data in Workers KV -Next we’ll define the `persistAuth` function to handle the request and parse the appropriate authorization info from it. Let’s begin by parsing the JSON body returned back from Auth0: +Next define the `persistAuth` function to handle the request and parse the appropriate authorization information from it. Begin by parsing the JSON body returned back from Auth0: ```js --- @@ -286,7 +286,7 @@ const persistAuth = async exchange => { } ``` -The `body` object — assuming no errors — will contain an `access_token`, `id_token`, and [other fields](https://auth0.com/docs/flows/guides/auth-code/add-login-auth-code#request-tokens) that we should persist inside of Workers KV, a key-value store that we can access inside of our Workers scripts. When we store data inside Workers KV we need to persist it using a key. The `id_token` field, which is returned by Auth0, is a [JSON Web Token](https://jwt.io) that contains a `sub` field, a unique identifier for each user. We’ll decode the JSON Web Token and parse it into an object: +The `body` object — assuming no errors — will contain an `access_token`, `id_token`, and [other fields](https://auth0.com/docs/flows/guides/auth-code/add-login-auth-code#request-tokens) that you should persist inside of Workers KV, a key-value store that we can access inside of our Workers scripts. When you store data inside Workers KV, you need to persist it using a key. The `id_token` field, which is returned by Auth0, is a [JSON Web Token](https://jwt.io) that contains a `sub` field, a unique identifier for each user. Decode the JSON Web Token and parse it into an object: ```js --- @@ -333,7 +333,7 @@ const persistAuth = async exchange => { } ``` -To ensure that the ID token we’ve received is valid, we should do a number of checks on the decoded token object, as per the [OpenID Connect Core 1.0 spec](https://openid.net/specs/openid-connect-core-1_0.html#IDTokenValidation). We’ll update the `persistAuth` function to validate the token — if it isn’t valid, we can return an object indicating that the response is invalid: +To ensure that the ID token you have received is valid, you should do a number of checks on the decoded token object, as per the [OpenID Connect Core 1.0 spec](https://openid.net/specs/openid-connect-core-1_0.html#IDTokenValidation). Update the `persistAuth` function to validate the token — if it is not valid, return an object indicating that the response is invalid: ```js --- @@ -355,14 +355,14 @@ const persistAuth = async exchange => { } ``` -Inside of `validateToken`, we’ll examine fields inside of the decoded token, ensuring that: +Inside of `validateToken` examine fields inside of the decoded token, ensuring that: - The `iss` field matches the `AUTH0_DOMAIN` secret - The `aud` field matches the `AUTH0_CLIENT_ID` secret - The `exp` field is after the current time - The `iat` field was issued in the last day -The code for this will use a `try/catch` block, throwing an error and returning false if any of the above criteria aren’t true: +The code for this will use a `try/catch` block, throwing an error and returning false if any of the above criteria are not true: ```js --- @@ -409,7 +409,7 @@ const validateToken = token => { } ``` -With the decoded JWT available and validated, we can hash and salt the `sub` value and use it as a unique identifier for the current user. To do this, we’ll use the [Web Crypto API](https://developer.mozilla.org/en-US/docs/Web/API/Web_Crypto_API) available inside the Workers runtime. We’ll combine the `SALT` value, a secret that we’ll set later in the tutorial, with the `sub` value. By creating a SHA-256 digest of these combined strings, we can then use it as the key for storing the user’s JWT in Workers KV: +With the decoded JWT available and validated, you can hash and salt the `sub` value and use it as a unique identifier for the current user. To do this, use the [Web Crypto API](https://developer.mozilla.org/en-US/docs/Web/API/Web_Crypto_API) available inside the Workers runtime. Combine the `SALT` value, a secret that you will set later in the tutorial, with the `sub` value. By creating a SHA-256 digest of these combined strings, you can then use it as the key for storing the user’s JWT in Workers KV: ```js --- @@ -428,9 +428,9 @@ const persistAuth = async exchange => { } ``` -Once the user’s authentication data has been stored in KV, we need to associate the user with that data. To do this, we’ll set a cookie, setting the value to the encrypted `id` string we just defined. +Once the user’s authentication data has been stored in KV, you need to associate the user with that data. To do this, set a cookie, setting the value to the encrypted `id` string you just defined. -This cookie will be used as we fill out the `verify` function defined earlier in the tutorial, and we’ll set it to expire in a day (though this is easily customizable to your application’s needs). To persist this cookie, we’ll return an object containing some data for a [Response](https://developer.mozilla.org/en-US/docs/Web/API/Response) instance, redirecting the user via an [HTTP 302 response](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/302) to the `/` path, with a `Set-cookie` header: +This cookie will be used as you fill out the `verify` function defined earlier in the tutorial. Set the cookie to expire in a day (though this is easily customizable to your application’s needs). To persist this cookie, return an object containing some data for a [Response](https://developer.mozilla.org/en-US/docs/Web/API/Response) instance, redirecting the user via an [HTTP 302 response](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/302) to the `/` path, with a `Set-cookie` header: ```js --- @@ -454,7 +454,7 @@ const persistAuth = async exchange => { } ``` -With our authorization logic defined, we can finally wrap up the corresponding code in `workers-site/index.js`. Knowing that the `handleRedirect` function will pass back an object with `Response` options, we can make a new `Response` object, passing in the information from the existing `response`, and adding the new headers and status code from `handleRedirect`. This will redirect the user to the app’s root path, setting a cookie to indicate that they’re authorized for future requests: +With our authorization logic defined, you can finally wrap up the corresponding code in `workers-site/index.js`. Knowing that the `handleRedirect` function will pass back an object with `Response` options, you can make a new `Response` object, passing in the information from the existing `response`, and adding the new headers and status code from `handleRedirect`. This will redirect the user to the app’s root path, setting a cookie to indicate that they are authorized for future requests: ```js --- @@ -484,9 +484,9 @@ async function handleEvent(event) { ## Implementing CSRF protection -To correctly protect against CSRF attacks, our application needs to provide a `state` parameter to the Auth0 login URL. When the user logs in and is redirected back to our application, we can compare the `state` parameter in the redirect URL to our previous piece of `state`, confirming that the user is beginning and ending the login flow via our application. +To correctly protect against CSRF attacks, our application needs to provide a `state` parameter to the Auth0 login URL. When the user logs in and is redirected back to our application, you can compare the `state` parameter in the redirect URL to our previous piece of `state`, confirming that the user is beginning and ending the login flow via your application. -We’ll generate this piece of state using `csprng.xyz`, a Cloudflare API service for generating random data. The API endpoint `csprng.xyz/v1/api` returns a JSON object with the key `Data` that we’ll use as the random value: +Generate this piece of state using `csprng.xyz`, a Cloudflare API service for generating random data. The API endpoint `csprng.xyz/v1/api` returns a JSON object with the key `Data` that you will use as the random value: ```json { @@ -496,7 +496,7 @@ We’ll generate this piece of state using `csprng.xyz`, a Cloudflare API servic } ``` -To persist this random data, we’ll use KV, persisting it for one day (86,400 seconds) before discarding it (note that this matches the `expires_at` time of the Auth0-provided `code` parameter). Replace the stubbed `generateStateParam` function in `workers-site/auth0.js` +The application will use Workers KV to persist this random data for one day (86,400 seconds), which is configured via the `expirationTtl` option. After one day, KV will automatically discard the `state-${state}` key. Replace the stubbed `generateStateParam` function in `workers-site/auth0.js` ```js --- @@ -512,9 +512,9 @@ const generateStateParam = async () => { ## Verifying the token and retrieving user info -With our application persisting authentication data in Workers KV and associating it to the current user via a cookie, we’re now prepared to fill out the `verify` function defined earlier in the tutorial. This function will look at the `Cookie` header, and look up the authentication info that we persisted in Workers KV. +With our application persisting authentication data in Workers KV and associating it to the current user via a cookie, you are now prepared to fill out the `verify` function defined earlier in the tutorial. This function will look at the `Cookie` header and try to locate the authentication information that you persisted in Workers KV. -To begin, install the NPM package [`cookie`](https://www.npmjs.com/package/cookie), which we’ll use to simplify parsing the `Cookie` header in the `request`: +To begin, install the NPM package [`cookie`](https://www.npmjs.com/package/cookie), which you will use to simplify parsing the `Cookie` header in the `request`: ```sh --- @@ -523,7 +523,7 @@ header: Install cookie package $ cd workers-site && npm install cookie ``` -In `workers-site/auth0.js`, we can begin to flesh out the contents of the `verify` function, beginning by parsing the `Cookie` header, looking for our `cookieKey` as defined earlier in the tutorial: +In `workers-site/auth0.js`, you can begin to write the contents of the `verify` function. Start by parsing the `Cookie` header, looking for your `cookieKey` as defined earlier in the tutorial: ```js --- @@ -543,7 +543,7 @@ const verify = async event => { } ``` -With the unique ID `sub` parsed from the `Cookie` header, we can use it to retrieve the user information we previously stored in KV. First, we’ll do a lookup to Workers KV using the `sub` field as a key — if it isn’t found, we’ll throw an `Error`. Next, we’ll take that data from Workers KV and attempt to parse it as JSON — if that fails, another `Error` will be thrown: +With the unique ID `sub` parsed from the `Cookie` header, use it to retrieve the user information you previously stored in KV. First, do a lookup to Workers KV using the `sub` field as a key — if it is not found, throw an `Error`. Next, take that data from Workers KV and attempt to parse it as JSON — if that fails, another `Error` will be thrown: ```js --- @@ -574,7 +574,7 @@ const verify = async event => { } ``` -Finally, we’ll decode the `idToken` stored in KV. This includes the `profile` and `email` scopes we requested from Auth0 when the user logged in, which we’ll return as `userInfo`, along with `accessToken` and `idToken`: +Finally, decode the `idToken` stored in KV. This includes the `profile` and `email` scopes you requested from Auth0 when the user logged in, which you will return as `userInfo`, along with `accessToken` and `idToken`: ```js --- @@ -608,7 +608,7 @@ const verify = async event => { } ``` -As a recap, this `verify` function will now correctly verify our application’s users based on the `Cookie` field and make any authorization information available as part of the `authorization` object: +As a summary, this `verify` function will now correctly verify your application’s users based on the `Cookie` field and make any authorization information available as part of the `authorization` object: ```js --- @@ -625,15 +625,15 @@ export const authorize = async event => { } ``` -By implementing this function, we’ve now completed the authorization/authentication portion of the tutorial! Our application will authorize any incoming users, redirecting them to Auth0 and verifying their access tokens before they’re allowed to see our Workers Site content. To configure your deployment and publish the application, you can skip to the “Publish” section, but in the next few portions of the tutorial, we’ll focus on some of the more interesting aspects of this project: using user information in our application, via “edge state hydration”, logging out our users, and some improvements and customizations that can be done to this application to make it ready for production usage. +By implementing this function, you have now completed the authorization/authentication portion of the tutorial. Your application will authorize any incoming users, redirecting them to Auth0 and verifying their access tokens before they are allowed to see your Workers Site content. To configure your deployment and publish the application, you can go to the [**Publish** section](/authorize-users-with-auth0#publish), but in the next few portions of the tutorial you will focus on some of the more interesting aspects of this project; for example, accessing user information within your application, “edge state hydration”, logging out users, and making the application more production-ready with some improvements and customizations. ### Improvements and customizations -This tutorial introduces concepts for implementing authentication in Workers using Auth0. There are several potential customizations and improvements to this codebase that are out-of-scope for this tutorial. I will briefly mention a few in this section, along with links to learn more. +This tutorial introduces concepts for implementing authentication in Workers using Auth0. There are several potential customizations and improvements to this codebase that are out-of-scope for this tutorial. This tutorial will briefly mention a few in this section, along with links to learn more. ### Using user data in our application -In the previous section of the tutorial, we made a request to Auth0’s `/userinfo` endpoint, which provides information such as name and email address for use in our application. Using Workers’ [HTML Rewriter](/runtime-apis/html-rewriter), we can embed the `userInfo` object that we’ve received from Auth0 directly into our site, by creating an instance of the `HTMLRewriter` class, and attaching a handler `hydrateState` to any found `head` tags that pass through the rewriter. The `hydrateState` handler will add a new `script` tag with an ID of `edge_state`, which we can parse and utilize in any front-end JavaScript code we’ll deploy with our application. Instead of simply returning `response` in `handleEvent`, we can replace it with the HTML rewriter code, and return a transformed version of `response`: +In the previous section of the tutorial, you made a request to Auth0’s `/userinfo` endpoint, which provides information such as name and email address for use in our application. Using Workers’ [HTML Rewriter](/runtime-apis/html-rewriter), you can embed the `userInfo` object that you received from Auth0 directly into your site by creating an instance of the `HTMLRewriter` class and attaching a `hydrateState` handler to any found `head` tags that pass through the rewriter. The `hydrateState` handler will add a new `script` tag with an ID of `edge_state`, which you can parse and utilize in any front-end JavaScript code you will deploy with your application. Instead of simply returning `response` in `handleEvent`, replace it with the HTML rewriter code and return a transformed version of `response`: ```js --- @@ -668,13 +668,13 @@ async function handleEvent(event) { } ``` -For a more detailed example of this functionality, check out the [source code](https://github.com/signalnerve/workers-auth0-example/) for this tutorial, which shows how to integrate this information using the JavaScript framework Alpine.js. In this example, the `userInfo` object is embedded into the `script#edge_state` tag, and when the site is rendered in the client’s browser, the user’s name (or email address, if the user’s name isn’t provided) is displayed: +For a more detailed example of this functionality, refer to the [source code](https://github.com/signalnerve/workers-auth0-example/) for this tutorial, which shows how to integrate this information using the JavaScript framework Alpine.js. In this example, the `userInfo` object is embedded into the `script#edge_state` tag, and when the site is rendered in the client’s browser, the user’s name (or email address, if the user’s name isn’t provided) is displayed: ![User info](./media/userInfo.png) ### Logging out users -While a user’s authentication cookie expires after a day, you may want to offer the ability for a user to log out manually. This is quite simple to implement — instead of letting the cookie expire automatically, your Workers application should pass a `Set-cookie` header that nulls out the `cookieKey` we previously defined. Let’s create a `logout` function in `workers-site/auth0.js`, and import it in `workers-site/index.js`, calling it when a user requests `/logout`: +While a user’s authentication cookie expires after a day, you may want to offer the ability for a user to log out manually. This is quite simple to implement — instead of letting the cookie expire automatically, your Workers application should pass a `Set-cookie` header that nulls out the `cookieKey` you previously defined. Create a `logout` function in `workers-site/auth0.js` and import it in `workers-site/index.js`, calling it when a user requests `/logout`: ```js --- @@ -721,14 +721,16 @@ async function handleEvent(event) { } ``` -In your Workers Site, you can add a “Log out” link, which will send users to the `/logout` route, and clear their auth cookie via the `Set-cookie` header: +In your Workers Site, you can add a **Log out** link, which will send users to the `/logout` route, and clear their auth cookie via the `Set-cookie` header: ```html Log out ``` -