Sign in through the admin app instead of this one #20

Merged
Paddy merged 3 commits from feature/admin-auth-cutover into master 2026-09-06 21:13:12 +00:00
Owner
No description provided.
Paddy added 3 commits 2026-09-06 21:12:25 +00:00
The frontend half of the calendar auth cutover (step 4 of
docs/calendar-auth-migration.md in the API repo). This app now shares one
identity with the tickets, feedback and admin apps.

Every call carries the session cookie via withCredentials rather than
appending sessionId/sessionKey to the URL, so there is no credential left in
api.service.ts at all - that was DEFERRED_SECURITY.md item 1.

The login and registration forms are gone. Accounts exist only by invitation
from the admin app, so both were one redirect; sign-out ends the session for
all four apps and returns here, so doing it by accident costs one click.

401 and 403 are deliberately not collapsed. Only 401 goes to the login page:
redirecting on 403 produces a loop where signing in succeeds and lands
straight back on the refusal, and doing it for an unreachable API produces the
same loop with no way out. Both of those now render a message instead.

src/app/models/session.ts and the unrouted LoginComponent are dead but left in
place; removing files is a separate decision.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Nothing has referenced it since the auth cutover: the session is an httpOnly
cookie this app can neither read nor construct, so there is no session type
for it to hold.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
From the same pre-deploy review. None of the four write calls had an error
callback, so a failure closed the row and saved nothing while looking exactly
like success. That was survivable when the session was a localStorage value
this app controlled; after the cutover a 401 is routine - the session expires,
or is ended from another app or another tab - so silence is not.

A 401 now says so and goes to the login carrying this page as the return
target; everything else says what happened and leaves the edits on screen.

getEvents had the same gap, and it is the one that matters during the deploy
itself: between the API going out and this bundle following it, the old code
renders as signed in and shows an empty table, which reads as "the calendar
lost its data" rather than "a deploy is in progress".

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Paddy merged commit f82255961b into master 2026-09-06 21:13:12 +00:00
Sign in to join this conversation.
No Reviewers
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: Nachklang/Calendar_Frontend#20