Skip to content

Cloudflare Worker: explain why you add the script, in its own section #119

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
forgetso merged 1 commit into from
Oct 20, 2026
Merged

Cloudflare Worker: explain why you add the script, in its own section #119

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
6 changes: 4 additions & 2 deletions src/content/docs/en/protect-edge/cloudflare-worker.mdx
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -36,7 +36,9 @@ Versioned tarballs are at `https://packages.prosopo.io/cloud/Prosopo-Cloudflare-

Part 2 (client-side) is hosted by us. You add two `<script>` tags to your pages, the second pointing at `https://js.protect.prosopo.io/protect.bundle.js`. Nothing to download or bundle yourself. We publish new versions to that URL; your pages pick them up on their next reload without a redeploy from you.

The worker never edits your pages, so you control where and when the bundle loads and the worker's response path stays a straight pass-through.
## Why the worker doesn't add the script for you

The worker never changes the pages your origin sends back. You add the Protect script to your own HTML, so you decide which pages load it, where it sits in the page and when it loads. The [Lambda@Edge integration](/protect-edge/lambda-edge) works the same way.

## Prerequisites

Expand Down Expand Up @@ -191,7 +193,7 @@ Worker verified? Move to Part 2.

**This part is mandatory.** Without the bundle no session cookie is ever set, and the worker returns 401 `no-session` on every protected path in perpetuity. The worker does not add it for you.

### 2a. Add the snippet
### 2a. Add the Protect script to your pages

Add this snippet to the `<head>` of every HTML page your site serves, as early as you can. A shared header template is the usual spot:

Expand Down
2 changes: 1 addition & 1 deletion src/content/docs/en/protect-edge/troubleshooting.mdx
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -77,7 +77,7 @@ Common block sources:
2. Filter for `protect.bundle.js`. If it's not there, the `<script>` tag isn't reaching your HTML. Check your header or footer template.
3. Filter for `/api/protect/init`. It should be a `POST` to `https://protect.<your-domain>` returning 200 with `Set-Cookie: prosopo_session=…`.

- If it's going to `https://js.protect.prosopo.io/api/protect/init` instead and getting a 405, your snippet is missing the `window.prosopo_config` block. Add it above the `<script src=…>` line. See [the CF Worker install step](/protect-edge/cloudflare-worker#2a-add-the-snippet).
- If it's going to `https://js.protect.prosopo.io/api/protect/init` instead and getting a 405, your snippet is missing the `window.prosopo_config` block. Add it above the `<script src=…>` line. See [the CF Worker install step](/protect-edge/cloudflare-worker#2a-add-the-protect-script-to-your-pages).
- If it's going to the right hostname but returning `4xx`, check the Portal settings and DNS.
4. Filter for cookies. The `prosopo_session` cookie should be set with `Domain=.<your-domain>` after the init call.

Expand Down
Loading