Alright, let's cut through the usual "it's magic" marketing. I've spent the last three days trying to onboard a simple internal tool behind Cloudflare Access. The setup is textbook: application subdomain, an allow policy for my team's email domain, and the one-click GitHub integration. The authentication flow *works*—I get the login screen, I authenticate, it redirects me...
...to a completely blank, white page. No console errors, no network calls failing, just void.
Before you ask, yes, I've done the basic troubleshooting:
- The origin server is reachable (curl from a non-Access IP works fine).
- The app itself loads fine when I bypass Access with a local hosts file entry.
- No funky headers are being stripped that I can see.
The most frustrating part is the lack of logs on Cloudflare's side that actually tell you what happens *after* the handoff to the origin. Zero. Nada.
My working theory is that it's either:
1. Something in the token or post-login redirect is mangling the session the app expects.
2. A silent conflict with an existing application cookie domain.
3. Yet another "helpful" Cloudflare feature (like Zaraz or a Page Rule) interfering that isn't obvious.
Has anyone else hit this particular brick wall? Specifically, with a non-trivial app (not a static site) that relies on its own session cookies? I'm looking for the *actual* gotchas, not the docs that just tell you to check your allow policy. What did you have to whitelist or reconfigure on your origin that they don't tell you?
trust but verify
Your theory about session cookie conflict is the most likely culprit. Cloudflare Access injects the `CF_Authorization` header post-authentication, but many applications have their own session cookies that can become misaligned with the new request domain. I've seen this cause a blank page when the app's client-side routing expects a valid session that the backend now rejects.
You mentioned the lack of logs after the handoff. That's a known pain point. You'll need to instrument your origin to log the raw incoming headers for the failing request, specifically the `Cookie` header and any `CF-*` headers. Often, the app's session cookie domain is set to `.yourdomain.com`, but the Access-protected subdomain creates a partition that the browser handles differently.
Try this: open developer tools *before* logging in, preserve the logs, and capture the exact redirect URL after GitHub auth. The query parameters there, particularly the `state` and any `prompt` values, can sometimes break the expected flow if the app uses OAuth state validation internally.
--perf
Blank page after auth handoff is almost always a client-side routing or cookie issue. Cloudflare's logs are useless post-handoff, that's by design.
Check your app's client-side router. SPAs often expect the root path `/` but Access might be redirecting to something like `/?auth_callback=...` that breaks the router's initial render. Look at the exact URL after the redirect in your address bar.
Also, manually inspect the cookies for that domain. Clear all of them, then try again. I've seen stale `sessionid` cookies from other subdomains block the app's own auth flow.
slow pipelines make me cranky
Ah yes, the classic "instrument your origin to log raw incoming headers." Practical advice, if you ignore the fact you need a logging pipeline for a simple internal app that used to work. That's the Access tax: you're now debugging an authentication wall that's supposed to simplify things.
Cookie domain partitioning is definitely a suspect, but the broader issue is assuming every app is a distributed OAuth client. Many internal tools are glorified monoliths with a simple session cookie. When Access injects a new auth scheme on a subdomain, you're not aligning cookies - you're running two separate auth systems that are now fighting.
Before you go down the logging rabbit hole, have you tried just setting `SameSite=None; Secure` on the app's session cookie? Sometimes it's that simple, because the browser decides the post-Access redirect is a cross-site request, even though it's technically your own domain.
monoliths are not evil