Segreti con default pubblico e nessun controllo all'avvio; session.permanent mai impostato #33
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
GRAVITÀ: media
FILE: src/frontend/flask_app/config.py:12,22 ; src/backend/config.py:14,19 ; docker-compose.yml:7,10 ; docker-compose.dev.yml:7,10 ; src/frontend/flask_app/blueprints/auth.py:85,121
COSA: DB_ROOT_PASSWORD, DB_PASSWORD, SERVER_SECRET_KEY, CLIENT_SECRET_KEY hanno default committati; un
.envincompleto parte in silenzio e le sessioni Flask diventano falsificabili (ruoli, is_admin).session.permanentmai impostato:PERMANENT_SESSION_LIFETIME=8hnon ha effetto. Il cookie contieneapi_keyin chiaro (firmato, non cifrato)./auth/logoutaccetta GET.VERIFICATO:
grep -rn permanent src/frontend/flask_app/*.py blueprints→ 0;grep -rn "change-this\|change_me" src --include=*.py→ solo i default.ORIGINE: revisione fable del 21/09/2026 su ramo
V3.0.0, commit8cc5e82. Documento completo:_output/2026-09-21-TieMeasureFlow-revisione.mdsu Wasabi.⚡ jeeg — preso in carico 2026-09-21T20:23:23Z
ramo:
lavoro/jeeg· capacità: docker, gpu, systemdANALISI (passo 1) — ramo
lavoro/jeeg, worktree~/lavoro/TieMeasureFlowsu jeeg, lotto A2+B2+C2MODIFICHE backend (A2): src/backend/config.py — all'avvio, se l'ambiente non è debug/test (usa il flag esistente; se non c'è, env APP_ENV != "dev"/"test") e
secret_keyo la password DB sono uguali al default committato → RuntimeError con messaggio che nomina la variabile.MODIFICHE frontend (B2): src/frontend/flask_app/config.py — stessa guardia su SECRET_KEY quando FLASK_DEBUG non è 1 e non TESTING. src/frontend/flask_app/blueprints/auth.py —
session.permanent = Trueal login;/auth/logoutsolo POST con CSRF (aggiorna il link nei template che lo chiamano: cercaauth.logoutin templates/ e trasformalo in form POST).MODIFICHE deploy (C2): docker-compose.yml — segreti senza default:
${DB_ROOT_PASSWORD:?manca DB_ROOT_PASSWORD}ecc. per DB_ROOT_PASSWORD, DB_PASSWORD, SERVER_SECRET_KEY, CLIENT_SECRET_KEY. docker-compose.dev.yml conserva i default (è sviluppo). .env.example: commento che in produzione sono obbligatori.TEST: config con default e ambiente produzione → errore; con TESTING/debug → parte. Logout GET → 405.
Soluzione
ESITO: fatto
COSA: Backend: con APP_ENV diverso da dev/test il server rifiuta di partire con secret key o password DB di default (verificato nell'immagine: RuntimeError). Frontend: guardia su CLIENT_SECRET_KEY fuori da debug/test,
session.permanent=True, logout solo POST. Compose di produzione: segreti e APP_DOMAIN obbligatori (${VAR:?}),APP_ENV: production.COMMIT (ramo lavoro/jeeg, unito su V3.0.0 a
d483fa1): 2de226f; 4384c48; a2f357b; 92f1304;920ab2fPROVA:
uv run --extra server --extra client --extra dev pytest -q→ 622 passed, 4 skipped (erano 391); visione su Python 3.13 → 16 passed (erano 8).