FACTUAL ACTIVITY RECORD · An activity record based on work that took place
Separating authentication boundaries for the public field and administration
Organizing viewing and administration through separate paths with a server-only key, explicit filters, and schema separation
Purpose
Data retrieval for displaying the 3D field and administrative operations for changing visible sessions had converged on the same authentication assumption. A clear boundary was needed so public viewing required no login while administration remained limited to a designated owner.
The aim was for the public API to return only required fields from allowed sessions without exposing a privileged key or direct database access to the browser, while both the administration page and API verify the authenticated identity.
Implementation
page implementation and endpoint implementation became unauthenticated public paths, while page implementation and endpoint implementation were separated as administration paths available only to the authenticated designated owner.
- administration-auth policy compares the JWT subject with the configured owner and distinguishes authorized, unauthenticated, and forbidden states.
- Administrative identity is checked in both administration-auth boundary and authentication proxy.
- Unauthenticated administration requests are directed to login, while a different authenticated user cannot proceed to administration data.
public-data adapter uses a Secret Key only on the server and explicitly filters every query by owner, project, and publicly allowed session. Direct browser Realtime database access was removed; the public interface now refreshes through periodic API retrieval and another retrieval when the page regains visibility.
The application became the source of truth for database migrations, with synchronization data moved into the codex schema and publication configuration into the app schema. Product-specific objects were removed from public, and grants plus row controls prevent anonymous and general authenticated users from directly accessing either schema.
- The Secret Key remains server-only and never receives a browser-public prefix.
- The public API returns only snapshots under allowed sessions and exposes neither administration queries nor free-form database access.
- Test identities and paths use synthetic values so personal-environment values are not included in the result.
administration-auth policy and synchronization adapter were added to check administrative identity and the owner, project, and session boundaries of public data. A fresh local database reset, schema smoke test, remote schema switch, key-specific access, and real HTTP responses were also checked.
The authorization boundary separated route classification from subject classification so public viewing was not coupled to the same browser authentication as owner-only administration.
Rendering diagram…
What was confirmed
Verification results
Thirty tests, lint, and the production build passed, along with a fresh local database reset and schema-split smoke test.
The server-only key could retrieve the required codex and app data, while direct access with the anonymous key was denied.
The public field and API returned 200 without authentication, while unauthenticated administration was redirected to login.
The live-mode public snapshot returned three allowed sessions and ten agents.
At the cutoff, the remote schema switch, Data API configuration, and public-administration boundary had been applied to the target. Additional defenses that would avoid relying on filtering after Secret Key exposure, and per-viewer authorization, were outside this scope.
Basis for completion
The scope was complete when separate public and administration paths, server-only retrieval, owner, project, and session filters, and schema and grant boundaries were present, local, remote, and HTTP checks passed, and the result was applied to the target.