feat: replace gorilla/sessions with alexedwards/scs/v2

Browser sessions are now server-side, stored in the SQLite database via
scs/sqlite3store (new `sessions` table, DB migration to version 12) instead
of gorilla/sessions client-side cookie storage. Only an opaque random token
is kept in the cookie; session data lives server-side and survives restarts.

Session middleware is wired as a hybrid to avoid buffering large responses:
scs.LoadAndSave on the login/logout write paths, and a non-buffering
read-only LoadSession middleware on the secured/config/frontend read paths
so the large GraphQL /query responses stream unbuffered. JWT-only APIs
(/api, /userapi, /api/metricstore) and static files are left unwrapped.

The session cookie Secure flag is now derived from the server config (set
when cc-backend terminates TLS itself); previously it was effectively never
set. The SESSION_KEY env var is removed as server-side tokens need no
signing secret. The dormant Bearer-JWT branch in the frontend urql client
is removed; the web UI authenticates GraphQL via the session cookie.

Closes #558

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Entire-Checkpoint: b51075f43cc7
This commit is contained in:
2026-06-17 07:54:26 +02:00
parent 3bfd3d06ca
commit 2b01b57495
15 changed files with 183 additions and 118 deletions

View File

@@ -152,6 +152,21 @@ ln -s <your-existing-job-archive> ./var/job-archive
./cc-backend -help
```
### Authentication and sessions
Browser sessions are stored server-side in the SQLite database (the `sessions`
table) using [`alexedwards/scs`](https://github.com/alexedwards/scs); only an
opaque random token is kept in the session cookie. No cookie-signing secret is
required, so the former `SESSION_KEY` environment variable is no longer used and
can be removed from your `.env`.
The session cookie's `Secure` flag is set automatically when cc-backend serves
HTTPS itself (i.e. `https-cert-file` and `https-key-file` are configured in
`config.json`); otherwise it is left unset so that plain-HTTP development works.
For production deployments, serve cc-backend over HTTPS so the session cookie is
marked `Secure`. If you terminate TLS at a reverse proxy, prefer letting
cc-backend serve HTTPS directly for now so the flag is applied.
## Database Configuration
cc-backend uses SQLite as its database. For large installations, SQLite memory