openrouter-watcher/export/githistory.md

Git History - OpenRouter API Key Monitor

Documentazione dei commit con contesto e motivazione.

---

2026-04-07: User Authentication Phase (T17-T22)

feat(schemas): T17 add Pydantic auth schemas

Commit: 02473bc

Contesto: Implementazione degli schemas Pydantic per l'autenticazione utente.

Motivazione:

• Separazione chiara tra dati di input (register/login) e output (response)
• Validazione centralizzata delle password con validate_password_strength()
• Supporto ORM mode per conversione automatica da modelli SQLAlchemy

Dettagli implementativi:

• UserRegister: email (EmailStr), password (min 12, validazione strength), password_confirm
• UserLogin: email, password
• UserResponse: id, email, created_at, is_active (from_attributes=True)
• TokenResponse: access_token, token_type, expires_in
• TokenData: user_id (Union[str, int]), exp

---

feat(auth): T18 implement user registration endpoint

Commit: 714bde6

Contesto: Endpoint per la registrazione di nuovi utenti.

Motivazione:

• Verifica email unica prima della creazione
• Hashing sicuro delle password con bcrypt
• Risposta che esclude dati sensibili

Dettagli implementativi:

• POST /api/auth/register
• Verifica esistenza email nel DB
• hash_password() per crittografare la password
• Ritorna UserResponse con status 201
• Errori: 400 per email duplicata, 422 per validazione fallita

---

feat(auth): T19 implement user login endpoint

Commit: 4633de5

Contesto: Endpoint per l'autenticazione e generazione JWT.

Motivazione:

• Verifica credenziali senza esporre dettagli specifici degli errori
• Generazione token JWT con scadenza configurabile
• Risposta standard OAuth2-like

Dettagli implementativi:

• POST /api/auth/login
• Ricerca utente per email
• verify_password() per confronto sicuro
• create_access_token(data={"sub": str(user.id)})
• Ritorna TokenResponse con status 200
• Errori: 401 per credenziali invalide

---

feat(auth): T20 implement user logout endpoint

Commit: b00dae2

Contesto: Endpoint per il logout formale (JWT stateless).

Motivazione:

• JWT sono stateless, il logout avviene lato client
• Endpoint utile per logging e future implementazioni (token blacklist)
• Richiede autenticazione per coerenza

Dettagli implementativi:

• POST /api/auth/logout
• Requiere current_user: User = Depends(get_current_user)
• Ritorna {"message": "Successfully logged out"}

---

feat(deps): T21 implement get_current_user dependency

Commit: 1fe5e1b

Contesto: Dipendenza FastAPI per estrarre utente autenticato dal token JWT.

Motivazione:

• Riutilizzabile in tutti gli endpoint protetti
• Validazione completa del token (firma, scadenza, claims)
• Verifica utente esista e sia attivo

Dettagli implementativi:

• Usa HTTPBearer per estrarre token da header Authorization
• decode_access_token() per decodifica e validazione
• Estrazione user_id dal claim "sub"
• Recupero utente dal DB
• HTTPException 401 per qualsiasi errore di autenticazione

---

test(auth): T22 add comprehensive auth endpoint tests

Commit: 4dea358

Contesto: Test suite completa per l'autenticazione.

Motivazione:

• Coverage >= 90% obbligatorio
• Test di casi limite e errori
• Isolamento dei test con database in-memory

Dettagli implementativi:

• TestClient di FastAPI con override get_db
• Fixture: test_user, auth_token, authorized_client
• Test schemas: 19 test per validazione
• Test router: 15 test per endpoint
• Coverage finale: 98.23%

---

Riepilogo Fase Authentication

Task	Commit	Test	Coverage
T17	02473bc	19	100%
T18	714bde6	5	100%
T19	4633de5	4	100%
T20	b00dae2	3	100%
T21	1fe5e1b	3	87%
T22	4dea358	-	-
Totale	6 commits	34	98.23%

Prossima fase: Gestione API Keys (T23-T29)

---

2026-04-07: API Token Management Phase (T41-T43)

feat(tokens): T41-T43 implement API token management endpoints

Commit: 5e89674

Contesto: Implementazione della gestione token API per l'accesso programmatico alla public API.

Motivazione:

• Gli utenti necessitano di token API per accedere alla public API (/api/v1/*)
• Sicurezza critica: token plaintext mostrato SOLO alla creazione
• Limite di token per utente per prevenire abuse
• Soft delete per audit trail

Dettagli implementativi:

T41 - POST /api/tokens:

• Auth JWT required
• Body: ApiTokenCreate (name: 1-100 chars)
• Verifica limite: MAX_API_TOKENS_PER_USER (default 5)
• Genera token con generate_api_token() → (plaintext, hash)
• Salva SOLO hash SHA-256 nel DB
• Ritorna: ApiTokenCreateResponse con token PLAINTEXT (solo questa volta!)
• Errori: 400 se limite raggiunto, 422 se nome invalido

T42 - GET /api/tokens:

• Auth JWT required
• Ritorna: List[ApiTokenResponse] (NO token values!)
• Solo token attivi (is_active=True)
• Ordinamento: created_at DESC
• Filtraggio per user_id (sicurezza: utente vede solo i propri)

T43 - DELETE /api/tokens/{id}:

• Auth JWT required
• Verifica ownership (403 se token di altro utente)
• Soft delete: set is_active = False
• Ritorna: 204 No Content
• Token revocato non funziona più su API pubblica (401)
• Errori: 404 se token non trovato, 403 se non autorizzato

Sicurezza implementata:

• ✅ Token plaintext mai loggato
• ✅ Solo hash SHA-256 nel database
• ✅ Token values mai inclusi in risposte GET
• ✅ Verifica ownership su ogni operazione
• ✅ Soft delete per audit trail

Test:

• 24 test totali
• 100% coverage su routers/tokens.py
• Test sicurezza critici: NO token values in GET, revoked token fails on public API

---

Riepilogo Fase API Token Management

Task	Descrizione	Test	Stato
T41	POST /api/tokens (generate)	8	✅ Completato
T42	GET /api/tokens (list)	7	✅ Completato
T43	DELETE /api/tokens/{id} (revoke)	9	✅ Completato
Totale		24	100% coverage

MVP Fase 1 completato al 52%! 🎉