[NestJS] Porter la route GET /api/v1/auth depuis le serveur Fastify vers server-nestjs #2225

Activity

1. shikanime

   added

   technical debtRésoud de la dette techniqueRésoud de la dette technique

   tech

   refactorRefactor codeRefactor code

   on Jun 17, 2026
2. shikanime

   changed the title [-][NestJS] Port POST /api/v1/auth route from Fastify server to server-nestjs[/-] [+][NestJS] Porter la route POST /api/v1/auth depuis le serveur Fastify vers server-nestjs[/+] on Jun 17, 2026
3. StephaneTrebel

   removed

   tech

   on Aug 10, 2026
4. shikanime

   self-assigned this

   on Aug 26, 2026
5. shikanime

   moved this to Backlog in Cloud Pi Nativeon Sep 29, 2026
6. shikanime

   added the

   Task

   issue type on Sep 29, 2026
7. shikanime

   added this to the 9.27.0 milestone on Sep 29, 2026
8. shikanime

   added a parent issue on Sep 29, 2026

   • [NestJS] Modularisation de server #1889
9. shikanime

   changed the title [-][NestJS] Porter la route POST /api/v1/auth depuis le serveur Fastify vers server-nestjs[/-] [+][NestJS] Porter la route GET /api/v1/auth depuis le serveur Fastify vers server-nestjs[/+] on Oct 6, 2026
10. shikanime commented on Oct 6, 2026

    

    shikanime

    on Oct 6, 2026

    MemberAuthor

    More actions

    Convergence — qualification contre le code réel (2026-10-06)

    Trois résolutions issues de la comparaison systématique du ticket avec
    origin/main : le périmètre initial a été écrit avant que le module user
    n'existe ; deux des trois prérequis qu'il listait sont désormais portés par
    l'existant, et le verbe de la route était faux.

    1. Le verbe est GET, pas POST. Le contrat partagé fait foi :

    // packages/shared/src/contracts/user.ts @ origin/main
    auth: {
      method: 'GET',
      path: `${apiPrefix}/auth`,
      summary: 'Login',
      description: 'OIDC callback to signin or signup',

    Le client consomme ce contrat (apiClient.Users.auth() dans
    apps/client/src/stores/user.ts). Le corps du ticket disait POST : corrigé.

    2. UserModule existe déjà. user.controller.ts sert déjà
    GET /api/v1/users, GET /api/v1/users/matching et PATCH /api/v1/users et la
    route location /api/v1/users de routing.conf pointe vers NestJS. Le ticket
    demandait de créer le module : seul le endpoint auth manque. Le service
    expose déjà PrismaService + EventEmitter2 ; toContractUser est réutilisable
    pour la réponse.

    3. Le vrai travail est la session, pas la route. Côté legacy,
    req.session.user est alimenté par la pile fastify-cookie + @fastify/session
    (sessionConf : cookie sessionId, httpOnly, secure, expires 30 min) remplie
    par fastify-keycloak-adapter via userPayloadMapper (sub → id,
    given_name → firstName, family_name → lastName, groups). Côté NestJS :
    aucun plugin de session enregistré dans main.ts, et AuthService ne couvre que
    dso-token et keycloak-jwt (header Authorization: Bearer). Or le client envoie
    déjà le token Bearer sur toutes les routes hors liste blanche
    (apps/client/src/api/xhr-client.ts). La qualification a donc tranché l'approche :

    • Option retenue — port du handler via le token Bearer existant :
      KeycloakJwtService.validatePayload implémente déjà la logique métier de
      logViaSession (findUnique user, upsert des adminRoleIds fusionnant groupes
      OIDC + rôles persistés + type: 'global', bitmask OR des permissions,
      lastLogin). Le handler devient un @Get('auth') dans le UserController
      existant qui délègue à AuthService.authenticate (ou directement à
      KeycloakJwtService), complète la création du user manquant
      (logViaSession crée avec type: 'human', validatePayload renvoie 401) et
      retourne le user complet via toContractUser. Aucune session Fastify à
      répliquer, aucun secret partagé legacy à porter.
    • Option écartée — répliquer @fastify/session : le cookie de session
      legacy et le Bearer du client coexistent dans la même requête ; aligner NestJS
      sur le mécanisme déjà émis par le client évite un troisième chemin
      d'authentification et la synchronisation de sessionSecret entre les deux
      backends.

    Divergence comportementale à décider pendant l'implémentation : la création à la
    volée d'un user absent (legacy : upsert type: 'human' ; NestJS actuel : 401).
    Le respect du contrat (200 avec UserSchema + 307 documenté) impose de porter
    la création, sinon tout premier login sur une route NestJS échoue.

    Le corps du ticket a été réécrit avec ce périmètre qualifié ; l'estimation
    ~2 j tient, l'essentiel étant l'écart create-vs-401 et la parité de réponse.
11. shikanime

    added a commit that references this issue on Oct 6, 2026

    feat(user): router la connexion GET /api/v1/auth vers server-nestjs

    ...

    9fccf56
12. shikanime

    linked a pull request that will close this issuefeat(auth): router la connexion GET /api/v1/auth vers server-nestjs #2824on Oct 6, 2026
13. shikanime

    linked a pull request that will close this issuefeat(nginx-strangler): router la connexion /api/v1/auth vers server-nestjs #2826on Oct 6, 2026
14. shikanime

    closed this as completedon Oct 6, 2026