docs: add Prosopo Protect (Edge) section with Cloudflare Worker guide - #51
Merged
Conversation
Replaces the one-paragraph mention of the disposable-domain blocklist with full coverage of the five-stage check chain (direct lookup, SSRF-safe validation, HTTPS redirect probe, CNAME chase, MX fallback), provider-side config (`spamEmailDomainsUrls`, scheduler cron) and the standalone `/v1/prosopo/provider/client/spam/email` endpoint with request/response examples. Also updates the evaluation-order list to reflect that the domain-list stage runs last (after the synchronous pattern rules) since it is the most expensive. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Cuts implementation detail that doesn't belong on customer-facing docs: the SSRF safety check, source-code paths, the provider-side feed URLs and cron config, and the per-step DNS-chase explanation. What's left: what the toggle does, what gets caught (including the redirect/CNAME/MX chase, named but not over-explained), the rejection status code, and the standalone endpoint contract. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
…tures Cross-language fixes (en + de/es/fr/it/pt-br): - Fix broken React integration links in welcome and client-side-rendering (pointed at /angular-integration/ instead of /react-integration/) - Fix invisible-captcha server-side example using reCAPTCHA-style fields (response/remoteip/result.success) instead of Prosopo's (token/ip/verified) - Fix server-side-verification SDK example: ProsopoServer requires a pair argument; isVerified returns a VerificationResponse object, not a boolean - Fix tier naming "Pro and Enterprise" -> "Professional and Enterprise" to match the Tier enum in the portal English-only: - Add ASN as a documented access-control rule field (already supported by the rule editor and policy schema, just undocumented) - Reword traffic-filter "Providing the IP Address" to lead with what actually happens (filters always run against the session-initiation IP; passing ip overrides with a fresh lookup) instead of implying the IP field is required Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Adds a new sidebar section that documents the two edge integrations (Lambda@Edge, Cloudflare Workers) and a full deploy guide for the CF Worker so users can go from zero to a live worker without leaving the docs. - src/content/docs/en/protect-edge/index.mdx — overview of the edge integration model, decision tree, correlation, and what lives in @prosopo/protect-edge-core vs the platform adapters. - src/content/docs/en/protect-edge/cloudflare-worker.mdx — install, seed-settings, deploy, verify, npm scripts, TLS caveats, proxy/VPN/datacenter blocking, troubleshooting. - src/i18n/en/nav.ts — new "Prosopo Protect (Edge)" nav section. Verified with `npm run check` (0 errors) and `npm run build` (both pages render at /en/protect-edge/ and /en/protect-edge/cloudflare-worker/). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
✅ Deploy Preview for peaceful-pothos-9e62ce ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
…eaders - New /protect-edge/lambda-edge/ page: prereqs, bundle-time config model (Lambda@Edge can't carry env vars, so BUMBLEBEE_URL and CLIENT_JWT are inlined at bundle time), deploy via Serverless Framework, npm scripts, verify, constraints (region, runtime, memory, time, bundle size), and troubleshooting. - Rewrites the overview and Cloudflare Worker pages to drop internal names and repo internals — no more "Bumblebee", "@prosopo/protect- edge-core", package-structure trees, or ansible paths. Site setup is framed as a dashboard/account-manager task rather than a script the client runs with the admin mnemonic. - Nav entry for the new Lambda@Edge page. Verified with `npm run check` (0 errors) and `npm run build` (326 pages built, all three protect-edge pages routed). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Both edge integration guides assumed the reader was cloning the source
and running the full toolchain. The actual client experience is: they
receive a JS bundle, upload it, attach it to the CDN behaviour they
want to protect. This rewrite matches that.
- Lambda@Edge: 2-step deploy (aws lambda create-function + publish-
version, attach the versioned ARN to a CloudFront behaviour). No
more references to Serverless Framework as a dev dep, npm scripts,
or vite/define internals.
- Cloudflare Worker: wrangler.toml template + wrangler deploy. No
more `cd protect/packages/cloudflare-worker && npm install`, no
bundle/build:tsc script table, no seed-settings walkthrough that
needed the admin mnemonic.
- Both docs drop internal implementation notes ("inlined at build
time via vite's define", "@prosopo/protect-edge-core", etc).
Blocking policy is framed as a dashboard task, not an admin API
call the client makes.
Verified: `npm run check` 0 errors, `npm run build` clean.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
…, gate proxy test on dashboard config - Both docs: reframe "When Prosopo issues a new bundle" as "your account manager will let you know when a new bundle is available". - Both docs: qualify the proxy/VPN verify curl — it only returns 403 if proxy/VPN blocking is enabled on the Prosopo dashboard. Without the guard, someone running the curl against a fresh site with default rules would see a 200 or 401 instead and think the install was broken. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
…cached)
The old wording ("budgeted to 500 ms") advertised the failure timeout
rather than the expected latency, which reads worse than reality.
Replace with the typical numbers first — sub-40 ms live, sub-2 ms on
cached lookups — and keep the 500 ms as a hard-timeout fallback.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Mirrors the latency numbers now surfaced on the Lambda@Edge doc (sub-40 ms typical, sub-2 ms cached, 500 ms hard timeout with fail-open). Also notes that blocked requests are strictly faster than unprotected ones on the block path — the worker returns immediately without an origin fetch. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Explain the DNS record clients need to create before deploying:
protect.<their-domain> CNAME protect.prosopo.io
and the matching CNAME entry on their Prosopo dashboard's site
settings. Prosopo uses that hostname to route TLS SNI to the right
site config, and TLS cert handling is managed by Prosopo for it.
Explicitly rejects NS delegation as an alternative — only CNAME is
supported.
CF Worker doc: mentions that BUMBLEBEE_URL in wrangler.toml should
point at the CNAMEd hostname (not protect.prosopo.io directly).
Lambda@Edge doc: notes the bundle is built against the CNAMEd
hostname, so credential rotation on the hostname means requesting
a fresh bundle.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Adds a new sidebar section documenting the Prosopo Protect edge integrations. Two pages:
X-Prosopo-Request-Id, split between@prosopo/protect-edge-coreand the platform adapters).Nav entry added to `src/i18n/en/nav.ts` between "Advanced Usage" and "Framework integrations".
Companion PR
Pairs with prosopo/Protect#392 which ships `@prosopo/cloudflare-worker` and the shared `@prosopo/protect-edge-core` package.
Test plan
🤖 Generated with Claude Code