Paddy
7aac07a013
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>
67 lines
2.9 KiB
Markdown
67 lines
2.9 KiB
Markdown
# 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:**
|
|
1. Add an `activation_expires` column to the `users` table (e.g. `DATETIME`).
|
|
2. Set it to `NOW() + INTERVAL 24 HOUR` in `createUser`.
|
|
3. 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.
|
|
|
|
**Fix:**
|
|
1. Add a `pw_reset_expires` column to the `users` table (e.g. `DATETIME`).
|
|
2. Set it to `NOW() + INTERVAL 15 MINUTE` in `initiatePasswordReset`.
|
|
3. Check `pw_reset_expires > NOW()` in `finalizePasswordReset` before accepting the token.
|