How sign-in works and who can read what¶

What this is for¶

This explains how people sign in to the cloud docs site and who is allowed to read which docs. No technical jargon required.

You reach a perimeter gate first (Cloudflare Access with a one-time code).
Then the app asks you to sign in with Google.
Both steps are required for protected pages. One alone is not enough.

Google sign-in uses a modern flow (OAuth with PKCE) so the browser never holds a shared secret for the app.

Who can read which docs¶

Each document has an intended reader group (for example, reviewers vs team test).
Those groups are listed in a manifest file that maps docs to audiences.
If you are not on the allowlist for that doc, you cannot read it. Access defaults to deny.

What happens if access is removed¶

When you sign in, the system takes a snapshot of who is allowed.
If someone is removed from the allowlist later, sessions already open may keep working until the app re-checks.
That “revocation lag” is a known behavior, not an accident of the design notes around WING-222 / WING-223 / WING-224.

What we have checked¶

With no one signed in, access control behaves as expected, and the secure sign-in setup is in place (checked 2026-07-30).
A full signed-in check with a real allowlisted Google account has not been completed yet; that work is deferred until such an account is available for testing.

What operators should watch¶

Some reader settings exist only in the live environment and are not fully declared on the deploy ladder.
Deploying from the ladder without those settings can break live sessions by stripping the configuration (RT-3).

Bottom line¶

Perimeter code + Google sign-in + per-doc allowlists. Deny by default. Live sessions may outlast a revoke until re-check. Ladder deploys must not drop the live-only reader settings.