This page is the app's-eye view of your request. Everything below arrived at the origin —
including anything Cloudflare injected in-flight. Watch the green rows: those are
identity headers stamped on by a Gateway policy, which the user can't fake.
No identity headers yet.Route this request through a Cloudflare Gateway HTTP policy that injects
X-User-Email: @{identity.email} (Allow action, TLS decryption on) and reload —
the verified identity will appear here, injected by Cloudflare, not by you.
Why is this empty? This page shows every header your request actually
carried — nothing is hidden. Identity headers only appear when your traffic passes
through a Gateway HTTP policy that injects them. For that to work, all three
must be true:
A Gateway HTTP Allow policy adds the headers (e.g. X-User-Email: @{identity.email}).
TLS decryption is ON — Gateway can't inject into HTTPS it can't decrypt.
The device is on Gateway with WARP, enrolled via SSO login — service-token / device enrollment carries no user identity, so @{identity.*} resolves empty.
Miss any one and there is genuinely nothing to inject — the empty state above is correct, not a bug.
☁️ Cloudflare edge headers added on the way in
cf-connecting-ipThe visitor's real IP as Cloudflare sees it (what the origin should trust).216.73.217.139
cf-ipcountryTwo-letter country Cloudflare geolocated the visitor to.US
cf-rayUnique ID for this request through Cloudflare — quote it in support/log lookups.a30c270abea5386c
cf-visitorJSON hint of the original scheme (http/https) the browser used.{"scheme":"https"}
true-client-ipEnterprise alias for the client IP — same value as CF-Connecting-IP.216.73.217.139
x-forwarded-protoThe protocol (https) the edge received the request on.https
📨 Everything else the origin received
acceptContent types the client will accept in the response.*/*
accept-encodingCompression methods the client supports (gzip, br).gzip, br
connectionKeep-Alive
hostThe hostname the browser requested.disney-pin-fanatic.itlinux.cc