Secrets hygiene: env cookie secret, untrack dev DB, close connection leak

[Alvin-Nahabwe]

What & why

Three fixes to the auth layer plus a gitleaks config.

1. Cookie-signing secret → environment (the real vulnerability)

server/auth.R hardcoded cookie_password = "aphrcpass1" in this public repo. That value is the key used to sign session cookies — with it public, a session cookie can be forged for any user, independent of the password database. It now reads COOKIE_PASSWORD from the environment and warns loudly if it falls back to the dev default.

Action required on deploy: set COOKIE_PASSWORD in the environment (this also invalidates existing sessions once, which is desired).

2. Untrack the committed dev database

users_db/users.sqlite (throwaway local-test accounts — confirmed no real users) was committed. Untracked it (already covered by .gitignore). Safe because:

• login::login_server recreates the tables on first run (dbWriteTable when the table is absent), and
• auth.R now creates the users_db/ directory and only runs its ALTER TABLE users when the table already exists — previously it would have crashed on a fresh DB with "no such table: users".

A fresh clone/deploy now boots cleanly with no committed database.

3. Close the login DB connection

The connection was opened per session and never closed (the "call dbDisconnect()" warnings from issues.md). Now closed on session$onSessionEnded.

4. gitleaks config

.gitleaks.toml allowlists the dev DB path and the dev cookie fallback so the secret scan (added in #176, currently advisory) can be flipped to blocking.

Verified

parse() passes on auth.R. Confirmed login::login_server auto-creates tables and uses salted SHA-512 (via digest) for passwords — the unsalted MD5 123456 hashes were only in the dev fixture, now untracked.

Follow-ups

• After CI: R parse check and secret scan #176 merges, flip the app's gitleaks job from advisory to blocking (one line).
• Consider a slow KDF (bcrypt/argon2) for passwords — needs a different auth package than login (which offers SHA-family salt_algo only). Recommendation, not urgent.

Note on history

Per your decision, no history rewrite — the dev DB remains in past commits (it's fake data). The allowlist keeps the scan clean.

🤖 Generated with Claude Code