Known Limitations & Security Notes

Open — production DEBUG mode

Status: open as of 2026-07-31, not confirmed resolved since. start_auth.bat does not set QDBAUTH_DEBUG, and settings.py defaults it to "1" (True) — meaning the production deployment was running with Django's DEBUG mode on, which leaks full stack traces, file paths, and server internals to anyone who hits a broken page. Fix: set QDBAUTH_DEBUG=0 in the production environment.

Open — unrotated shared secret and an exposed credential in the launch script

Status: open as of 2026-07-31, not confirmed resolved since. start_auth.bat (tracked by this repo) sets QDB_SSO_SHARED_SECRET to the unchanged default placeholder value from settings.py — never rotated to a real secret — and separately contains a real third-party mail-account credential written in plaintext. This secret gates every /api/* endpoint except /api/whoami/, so an unrotated, publicly-known default value undermines that entire gate. Fix: rotate QDB_SSO_SHARED_SECRET to a real, non-default value not committed to version control, and move the mail credential out of the tracked file into an untracked env source — coordinate the secret rotation with every consuming app's matching value at the same time (it's a breaking change for whoever holds the old value).

Resolved — auth failures returned HTTP 200

Status: resolved 2026-07-28. /api/login/ and /api/verify-2fa/ used to return HTTP 200 with success:false for wrong password/code, making it easy for a caller to mishandle the failure as success. Now returns 400. See Changelog.

Limitation — no self-service MFA recovery

If a user loses their authenticator device, there is no self-service "lost my phone" flow. An admin must use the force-re-auth action to issue a fresh QR code. See Authentication, MFA & Token Internals.

Limitation — one role column, no multi-group resolution

A user granted access to two sites that each define a different custom role group (ROLE_GROUPS) can't hold two independent role values — role is one column on users. Not an issue today (only TD customizes roles), but would need a real design decision if a second site adds its own role list. See Roles, Permissions & Multi-Tenancy.

Limitation — no tenant isolation

QDBAuth is not multi-tenant in the Keycloak sense — one global user pool shared by every consuming app. See Roles, Permissions & Multi-Tenancy for the full explanation and the closest equivalent concept ("sites").

Limitation — single point of failure

QDBAuth is presently a single server (no redundancy) — if it's down, no consuming site can authenticate anyone. A hosting/reliability plan (cloud auto-recovery + longer-lived, locally-verified tokens) was proposed 2026-07-31; not yet implemented. See Overview's Reliability section.

Open — pending database migration (per-site credentials)

Status: confirmed open as of 2026-07-28 (a live ProgrammingError was observed); current status unconfirmed. db/create_user_site_credentials_table.sql must be run against the live qdb database before granting any user access to more than one site (or before creating any new user at all, if the admin dashboard's create-user flow now always writes to this table). Symptom: Table 'qdb.user_site_credentials' doesn't exist. See Administrator User Guide's troubleshooting section.