Files

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

2.4 KiB

Raw Blame History

📋 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 :

StockController.java - /api/v1/stocks ❌ Pas de StockResource dans adapter/http
BonCommandeController.java - /api/v1/bons-commande ❌ Pas de BonCommandeResource dans adapter/http
ChantierController.java - /api/v1/chantiers ⚠️ DOUBLON : ChantierResource existe déjà dans adapter/http
MaterielController.java - /api/v1/materiels ⚠️ DOUBLON : MaterielResource existe déjà dans adapter/http
EmployeController.java - /api/v1/employes ⚠️ À vérifier si EmployeResource existe
EquipeController.java - /api/v1/equipes ❌ À vérifier
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

Endpoints en double : Si on garde les deux, Quarkus peut lever des erreurs de routes dupliquées
Incohérences : Les controllers peuvent avoir une logique différente des Resources
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

2.4 KiB Raw Blame History