Files

T

Paddy 7aac07a013 Add admin identity module: better-auth, per-app permissions, invitations

Introduces src/models/admin/, a dedicated identity and permissions module on
its own nachklang_admin database, and the shared authenticator that feedback
and tickets will move onto in the cutover step. Nothing swaps over yet:
feedback.auth.ts and tickets.auth.ts still authenticate against the legacy
calendar sessions, so production behaviour is unchanged.

- better-auth 1.7 mounted at /admin/auth/*, sessions as httpOnly cookies
  scoped to .nachklang.art so one sign-in covers every *.nachklang.art app.
- Accounts are invite-only: public sign-up is disabled, and the invitations
  plugin is the only code that creates users. Tokens are stored as SHA-256
  hashes and travel in the request body, never in a URL.
- Per-app permissions in user_app_permissions; requireAppAccess(app) queries
  the database on every request (no cookie cache) so disabling a user or
  revoking a session takes effect immediately.
- ADMIN_BOOTSTRAP_EMAIL guarantees a way in on an empty database, idempotently
  and without crashing the API if the database is unreachable at boot.
- Guards prevent an admin from removing their own admin permission, disabling
  themselves, or stripping the last active admin.

The admin pool uses the callback-style mysql2, not mysql2/promise: Kysely's
MysqlDialect drives the pool with callbacks, and the promise wrapper ignores
them, so every query hangs silently. Only the integration tests caught this.

Schema in sql/admin/001_init.sql, derived from getAuthTables() on the
installed better-auth rather than the published CLI, which lags the library
and omits account.issuer.

app.ts is split into src/app.factory.ts so the integration tests drive the
real middleware order rather than a copy of it.

Tests: 131 unit, plus 41 integration tests against a throwaway MariaDB
started by test/integration/setup.ts (docker or podman).

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

2026-09-05 18:03:08 +02:00

2.9 KiB

Raw Blame History

Deferred Security Issues

These items were identified during a security review on 2026-05-02 and consciously deferred. Must be addressed before opening the application to a larger or public userbase.

1. Session credentials in URL query parameters (logged-in users)

Files: src/models/calendar/events/events.router.ts — all GET/PUT/DELETE handlers

sessionId and sessionKey are currently read from query parameters, which means they appear in server access logs, browser history, proxy logs, and Referer headers.

Fix: Move to request headers (X-Session-Id / X-Session-Key) or the request body. Requires a corresponding frontend update.

Note: the shared calendar password parameter in query params is intentional (iCal clients don't support headers) and is acceptable for the current setup.

2. No event ownership check

Files: src/models/calendar/events/events.router.ts

PUT /:eventId (update)
PUT /move/:eventId (move)
DELETE /:eventId (delete)

Currently any active user can edit, move, or delete any event regardless of who created it. This is acceptable while all users are trusted admins.

Fix: When non-admin users are introduced, fetch the event first and verify event.createdById === user.userId before allowing the mutation. Add an isAdmin flag to the user model to let admins bypass the check.

3. Activation token has no expiry

Superseded for new accounts (2026-09-05). The admin module (src/models/admin/) replaced account creation for the feedback, tickets and admin apps: accounts now come from invitations, whose tokens expire after 7 days and are stored only as a SHA-256 hash. The item below still stands for the legacy calendar users table, which the admin module deliberately left alone - see docs/calendar-auth-migration.md.

File: src/models/calendar/users/users.service.ts — createUser / activateUser

The email activation link is valid indefinitely. Acceptable for a small, trusted userbase.

Fix:

Add an activation_expires column to the users table (e.g. DATETIME).
Set it to NOW() + INTERVAL 24 HOUR in createUser.
Check activation_expires > NOW() in activateUser before accepting the token.

4. Password reset token has no expiry

Superseded for new accounts (2026-09-05). Password resets for admin-module accounts go through better-auth, whose reset tokens expire after one hour. As with item 3, the text below still applies to the legacy calendar users table.

File: src/models/calendar/users/users.service.ts — initiatePasswordReset / finalizePasswordReset

The reset token stored in pw_reset_token_hash never expires. Acceptable for a small, trusted userbase.