Day 54 of 55 · Friday · Learning

Zero-trust 302s - teaching your own automation to knockCapability

The daily 'pdb.zorc.app verification failed (302)' is Cloudflare Access working as designed against a curl that never learned to knock. Service tokens are the knock.

Catch-up progress

54/55

Why this matters to you

Every morning the deploy verify leg reports the live page failed because an unauthenticated request gets a 302 to the Access login. Meanwhile the pages.dev preview URL from the same deploy serves identical content to anyone holding the link — the alarm points at the locked front door while the side gate stands open.

Cloudflare Access is a zero-trust gate: every request to pdb.zorc.app must present identity — normally a browser login session. Zero-trust means no request is trusted by network position alone; a curl from your own Mac is as anonymous as one from anywhere. The 302 isn't an outage — it's the policy answering 'who are you?' to a client with no answer.

Service tokens are how automation answers. You mint a Client ID + Client Secret pair in the Cloudflare dashboard, add an Access policy that accepts it, and your script sends both as headers (CF-Access-Client-Id / CF-Access-Client-Secret). The verify leg then sees the real 200 from the real domain — no browser, no cookie jar.

Two sharp edges worth knowing this month. First: your preview deployments (the 2a28f6c6.pdb-eev.pages.dev-style URLs logged every morning) are NOT behind Access — anyone with a URL reads your daily plan. Second: Cloudflare just shipped Access-policy-attach for Workers with private-by-default previews, which is designed to close exactly that gap — it's the adopt question on this week's review card.

Worked example

Watch the gate answer, then see what an authenticated knock looks like.

curl -s -o /dev/null -w '%{http_code} -> %{redirect_url}\n' https://pdb.zorc.app/plan-day/today.html
curl -s -o /dev/null -w '%{http_code}\n' \
  -H "CF-Access-Client-Id: <token-id>.access" \
  -H "CF-Access-Client-Secret: <secret>" \
  https://pdb.zorc.app/plan-day/today.html

The first curl shows the 302 and WHERE it redirects — you'll see the cloudflareaccess.com login URL, proof this is policy, not breakage.
The second is the shape of the fix: same URL, two headers, 200 — run it for real once you've minted a token and added it to the Access policy.

▶ Do it now

Run the first curl and read the redirect URL — confirm for yourself it's the Access login, not an error page.
In the Cloudflare dashboard (Zero Trust → Access → Service Auth), mint a service token named pdb-verify and add it to the pdb.zorc.app application policy.
Store the pair outside git (e.g. ~/.config/pdb/access-token, chmod 600), wire the two headers into the verify curl, and watch tomorrow's log report 200 from the canonical domain for the first time.

Gotchas

Service tokens expire (default 1 year) — note the date somewhere a future health check can see, or the 302 quietly returns (the expiring-defaults lesson from July).
The token authenticates the SCRIPT, not you — anyone who reads the secret can pass the gate; keep it out of the repo and out of LaunchAgent plists.
Preview URLs bypass Access entirely on Pages today — treat every pages.dev link in a log as public until the private-preview feature is adopted.

Go deeper: Cloudflare Access service tokens

One-card takeaway

A 302 from a zero-trust gate is a question, not a failure — give your automation an identity and the question goes away.

← Prev Index Next →