← Security

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.

Authorization is required Google Account session-backed login persistent SSE

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.

© Harold Abelson: "Programs must be written for people to read, and only incidentally for machines to execute."

Google Session Auth Handler Application entry point
<?phpdeclare(strict_types=1);namespace App\Application\Handler\PayloadHandler\Example;use Semitexa\Core\Attribute\AsPayloadHandler;use Semitexa\Core\Contract\TypedHandlerInterface;#[AsPayloadHandler(payload: \App\Application\Payload\Request\ExamplePayload::class, resource: \App\Application\Resource\Response\PageResource::class)]final class GoogleSessionAuthHandler implements TypedHandlerInterface{    public function handle(\App\Application\Payload\Request\ExamplePayload $payload, \App\Application\Resource\Response\PageResource $resource): \App\Application\Resource\Response\PageResource    {        return $resource            ->withTitle('Example feature')            ->withSummary('Keep handlers small, declarative, and centered around the payload contract.');    }}

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.

Support Semitexa
Built for developers who prefer control over magic. Your support helps keep it fast, open, and evolving.

Donate via PayPal