Put the feedback and tickets admin areas behind the shared identity #13

2026-09-06T12:47:20Z

Paddy commented

2026-09-06 12:47:20 +00:00

No description provided.

Paddy added 2 commits 2026-09-06 12:47:20 +00:00

Put the feedback and tickets admin areas behind the shared identity 2405625f99

feedback.auth.ts and tickets.auth.ts each become one binding to
requireAppAccess. Everything downstream was already written against
requireAdminAuth and res.locals.admin, and both still mean what they
meant, so no router or service changed. What changed is the policy: an
activated @nachklang.art account is no longer sufficient, an explicit
per-app permission is.

Three things followed from that and are not obvious from the diff:

- APP_ORIGINS gets a production default. It feeds better-auth's
  trustedOrigins, and this is the first time the tickets and feedback
  origins matter there - before, the only browser origin that ever
  reached /admin/auth was the admin app itself. An origin missing from
  that list fails in a way that is easy to misread: sign-in works, the
  app works, and only sign-out returns an origin error.

- Nothing reads X-Session-* any more; these two files were the last
  readers, and the calendar module passes its session in query
  parameters. The headers stay in the CORS allowedHeaders only so a
  browser still running a pre-cutover bundle gets a clean 401 rather
  than a preflight failure, and can come out once both frontends are
  deployed.

- 40 admin operations documented a required X-Session-Id/X-Session-Key
  in swagger. They now declare the AdminSessionCookie scheme the admin
  module already defined, and each documents a 403 next to its 401.

The integration assertions flip as their own comment predicted: one
admin cookie opens both /feedback/admin/me and /tickets/admin/me, a
user holding only feedback gets 200 and 403 respectively, and a legacy
header session gets 401. The unit test that covered the old header
authenticator is replaced by one asserting each module is bound to its
own app and that neither consults the calendar users service.

163 unit tests and 43 integration tests green.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

Update the deferred-security advice for the cutover 9811610d55

DEFERRED_SECURITY.md item 1 still told the calendar to move its session
credentials from query parameters into X-Session-Id/X-Session-Key. That
was the right advice when two other modules read those headers; both
stopped in the cutover, so following it now would build a second
mechanism just as the first is being retired. The fix is the shared
admin identity, which closes the item outright rather than moving the
credential somewhere safer.

Also annotates the one assertion in auth-binding.ts that cannot
currently fail. It is kept deliberately - it is a tripwire against
someone reintroducing a header-session fallback for calendar users who
have not been invited yet, which is the shortcut this whole step exists
to close - but that was worth saying out loud rather than leaving it to
look like an oversight.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

Paddy merged commit 3c892d02ed into master

2026-09-06 19:06:30 +00:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: Nachklang/API#13