Files
btpxpress-backend/ANALYSE_CONTROLLERS.md
DahoudG 7df5f346f1 Refactor: Backend Frontend-Centric Auth - Suppression OIDC, validation JWT
Architecture modifiée pour Frontend-Centric Authentication:

1. **Suppression des dépendances OIDC**
   - quarkus-oidc → quarkus-smallrye-jwt
   - quarkus-keycloak-authorization → quarkus-smallrye-jwt-build
   - Le backend ne gère plus l'authentification OAuth

2. **Configuration JWT simple**
   - Validation des tokens JWT envoyés par le frontend
   - mp.jwt.verify.publickey.location (JWKS de Keycloak)
   - mp.jwt.verify.issuer (Keycloak realm)
   - Authentification via Authorization: Bearer header

3. **Suppression configurations OIDC**
   - application.properties: Suppression %dev.quarkus.oidc.*
   - application.properties: Suppression %prod.quarkus.oidc.*
   - application-prod.properties: Remplacement par mp.jwt.*
   - Logging: io.quarkus.oidc → io.quarkus.smallrye.jwt

4. **Sécurité simplifiée**
   - quarkus.security.auth.proactive=false
   - @Authenticated sur les endpoints
   - CORS configuré pour le frontend
   - Endpoints publics: /q/*, /openapi, /swagger-ui/*

Flux d'authentification:
1️⃣ Frontend → Keycloak (OAuth login)
2️⃣ Frontend ← Keycloak (access_token)
3️⃣ Frontend → Backend (Authorization: Bearer token)
4️⃣ Backend valide le token JWT (signature + issuer)
5️⃣ Backend → Frontend (données API)

Avantages:
 Pas de secret backend à gérer
 Pas de client btpxpress-backend dans Keycloak
 Séparation claire frontend/backend
 Backend devient une API REST stateless
 Tokens gérés par le frontend (localStorage/sessionStorage)

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude <noreply@anthropic.com>
2025-10-31 17:05:11 +00:00

61 lines
2.4 KiB
Markdown

# 📋 ANALYSE DES CONTROLLERS DANS presentation/controller
**Date** : 2025-10-29
**Status** : Analyse en cours
---
## 🎯 RÉSUMÉ
Les controllers dans `presentation/controller/` utilisent les mêmes patterns que les Resources dans `adapter/http/`, mais semblent être des doublons ou des versions anciennes.
### Controllers identifiés :
1. `StockController.java` - `/api/v1/stocks` ❌ Pas de StockResource dans adapter/http
2. `BonCommandeController.java` - `/api/v1/bons-commande` ❌ Pas de BonCommandeResource dans adapter/http
3. `ChantierController.java` - `/api/v1/chantiers` ⚠️ **DOUBLON** : ChantierResource existe déjà dans adapter/http
4. `MaterielController.java` - `/api/v1/materiels` ⚠️ **DOUBLON** : MaterielResource existe déjà dans adapter/http
5. `EmployeController.java` - `/api/v1/employes` ⚠️ À vérifier si EmployeResource existe
6. `EquipeController.java` - `/api/v1/equipes` ❌ À vérifier
7. `PhaseChantierController.java` - `/api/v1/phases-chantier` ❌ À vérifier
---
## 🔍 PLAN D'ACTION RECOMMANDÉ
### Option 1 : Migration vers adapter/http (RECOMMANDÉ)
- **StockController** → Créer `StockResource.java` dans `adapter/http/`
- **BonCommandeController** → Créer `BonCommandeResource.java` dans `adapter/http/`
- **EmployeController** → Vérifier si doublon ou migrer
- **EquipeController** → Vérifier si doublon ou migrer
- **PhaseChantierController** → Vérifier si doublon ou migrer
### Option 2 : Supprimer les doublons
- **ChantierController** → ❌ SUPPRIMER (ChantierResource existe)
- **MaterielController** → ❌ SUPPRIMER (MaterielResource existe)
---
## ⚠️ RISQUES
1. **Endpoints en double** : Si on garde les deux, Quarkus peut lever des erreurs de routes dupliquées
2. **Incohérences** : Les controllers peuvent avoir une logique différente des Resources
3. **Maintenance** : Avoir deux implémentations est source de confusion
---
## 📝 ACTION IMMÉDIATE
**PRIORITÉ P0** :
- ✅ Analyser les différences entre ChantierController et ChantierResource
- ✅ Analyser les différences entre MaterielController et MaterielResource
- ✅ Décider : migrer ou supprimer
**PRIORITÉ P1** :
- Créer StockResource dans adapter/http (si StockController a une logique utile)
- Créer BonCommandeResource dans adapter/http (si BonCommandeController a une logique utile)
---
**Status** : ⏸️ En attente de décision