SECURITY FEATURE
Google Authorization
This demo gates long-lived SSE surfaces behind a Google Account so the stream cannot be opened by anonymous traffic.
Feature Guide
A quick orientation block that answers the essential questions: what this feature does, how it works, why it matters, and the key concepts behind it.
What this does
Google Authorization adds a simple browser-facing login gate for demo SSE surfaces that keep a long-lived backend connection open.
How it works
A dedicated Google OAuth flow stores the verified account in the session. The demo SSE runtime then checks the existing session key before opening a persistent connection, so anonymous traffic cannot fan out unlimited streams.
Why it matters
This keeps the showcase safe enough for a public demo while still using the existing Semitexa auth/session pipeline instead of inventing a one-off bypass.
Key concepts
- Authorization is required
- UI label shown on gated demo blocks before login.
- Google Account
- The identity provider used for the demo authorization gate.
- persistent SSE
- A long-lived server-sent events connection that stays open after the initial page render.
Google Account
Authorization gate
Authorization is required before the demo can open long-lived SSE connections.
Verified against Semitexa Ultimate 2026.09.19.1020
Google Authorization
Authorization is required for demo SSE blocks that keep a long-lived backend connection open.
How it works
The Google OAuth flow begins with a redirect to the authorization URL, stores a CSRF state token in the session, receives the callback code, exchanges it for an access token, fetches the user profile, and writes a typed identity payload into the session. The #[AsAuthHandler] on GoogleSessionAuthHandler re-hydrates the principal on every subsequent request.
Why this matters
Long-lived SSE streams opened by anonymous traffic are a resource problem. Gating the stream behind an authenticated session means the connection carries a verified identity, and the server can close the stream cleanly if the session expires.
How it works
A dedicated Google OAuth flow stores the verified account in the session. The demo SSE runtime then checks the existing session key before opening a persistent connection, so anonymous traffic cannot fan out unlimited streams.
Why it matters
This keeps the showcase safe enough for a public demo while still using the existing Semitexa auth/session pipeline instead of inventing a one-off bypass.
Key concepts
- Authorization is required
- UI label shown on gated demo blocks before login.
- Google Account
- The identity provider used for the demo authorization gate.
- persistent SSE
- A long-lived server-sent events connection that stays open after the initial page render.