fix: break cloudflare managed challenge loop#1065
Draft
lidel wants to merge 3 commits into
Draft
Conversation
Cloudflare's Managed Challenge lands the visitor on a URL with a single-use __cf_chl_tk token. The SW installer reloads that URL, Cloudflare sees the replayed token, and challenges again. Strip every __cf_* param at the edge and 302 to the clean URL so reloads and shared links no longer carry challenge state.
Origin returns 200 for every SPA route via the _redirects rewrite, so 3xx is anomalous. The 4xx/5xx exclusion also keeps Cloudflare's own challenge response (403 with cf-mitigated: challenge) out of the normalized cache key.
The /ipfs/ and /ipns/ to subdomain mapping is deterministic, but the synthesized 301 never hit the edge cache. Cache it via caches.default keyed by source URL so repeat hits skip CID parsing and multibase decode. Strip __cf_* params before keying the cache and the Location so per-visitor challenge tokens share one cache entry and never leak onto the subdomain (snippet 02 would otherwise strip them in a second hop).
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
1 participant
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.
Note
This is not critical, but nice-to-have if we want to limit inbrowser.link/dev to real humans.
Problem
I did a test with Managed Challenge on
inbrowser.devto curb non-human traffic (AI crawlers pretending to be browsers etc).Visitors were getting an infinite Cloudflare challenge. After passing the challenge, Cloudflare sends you to
/?__cf_chl_tk=<one-time-token>but injected JS has not oportunity to strip it. The service worker installer on that page reloads the URL to take over, Cloudflare sees the already-used token a second time, assumes buggy bot and serves a fresh challenge. Repeat.This made me disable
managed challenge for alloninbrowser.devfor now.Solution
The Cloudflare snippet (
02) now strips every__cf_*query param at the edge and 302s to the clean URL, so the token is consumed once and the app never sees it.Two related cleanups, one commit each:
02caches only 2xx. unexpected 3xx , or Cloudflare's own 403 challenge response, no longer land in the installer cache. feels safer, protects us from misconfigurations (ours or Cloudflare's)01caches its path-to-subdomain 301 at the edge viacaches.default, with the same__cf_*strip so any per-visitor tracking tokens share one cache entry instead of fragmenting it.301right now, but as people start usinginbrowser.link/ipfs/{cid}more often, the redirect to subdomain could cost us meaningful cache missesTesting
Once deployed to
inbrowser.dev, we can enablemanaged challenge for allSecurity Rule forinbrowser.devto see if infinite loop is gone, and HTTP 301s get cached