Aller au contenu

Auth Token Flows For Front

Ce document liste les changements front à appliquer en même temps que la refonte backend des flows tokenisés.

Règle générale

  • les liens email/web-mobile entrants restent en ?token=...
  • le front ne doit plus appeler d'API avec le token dans le path
  • le front lit token depuis l'URL, appelle une API POST avec { "token": "..." }, puis nettoie l'URL locale
  • les flows tokenisés doivent fonctionner de la même façon sur web, app mobile, webview, universal links et app links

Nouvelles URLs front

  • activation compte: /account-activation?token=...
  • reset password: /password-reset?token=...
  • vérification changement email: /change-email?token=...
  • confirmation waitlist: /waitlist-confirmation?token=...
  • invitation waitlist: /waitlist-invitation?token=...
  • invitation utilisateur: /user-invitation?token=...
  • invitation adhérent structure: /structure-adherent-invitation?token=...

Nouvelles API à appeler

  • créer un compte direct: POST /v1/public/accounts
  • vérifier dispo pseudo: POST /v1/public/pseudos/availability
  • finaliser activation: POST /v1/public/account-activation/complete
  • renvoyer lien activation: POST /v1/public/account-activation/reissue
  • demander reset password: POST /v1/public/password-reset/request
  • finaliser reset password: POST /v1/public/password-reset/complete
  • confirmer changement email: POST /v1/public/change-email/complete
  • inscription waitlist: POST /v1/public/waitlist-entries
  • confirmer waitlist: POST /v1/public/waitlist-confirmations/confirm
  • créer compte depuis invitation waitlist: POST /v1/public/waitlist-invitations/signup
  • créer compte depuis invitation utilisateur: POST /v1/public/user-invitations/signup
  • résoudre invitation adhérent structure: POST /v1/public/structure-adherent-invitations/resolve
  • créer compte depuis invitation adhérent structure: POST /v1/public/structure-adherent-invitations/signup
  • refuser invitation adhérent structure: POST /v1/public/structure-adherent-invitations/decline
  • accepter invitation adhérent structure sur compte existant: POST /v1/web/api/structure-adherent-invitations/accept
  • créer invitation utilisateur connecté: POST /v1/web/api/me/user-invitations
  • créer invitations adhérents structure: POST /v1/web/api/structures/{idStructure}/adherent-invitations
  • lister la waitlist admin: GET /v1/web/api/admin/waitlist
  • bulk invite waitlist admin: POST /v1/web/api/admin/waitlist-invitations/bulk
  • resend invite waitlist admin: POST /v1/web/api/admin/waitlist-invitations/reissue

Payloads

Inscription waitlist

{
  "email": "alice@example.com",
  "accountType": "individual",
  "cityId": 12,
  "sportIds": [1, 2],
  "challengeToken": "token"
}

accountType est obligatoire. Valeurs autorisées: individual, pro.

Le backend ne fait pas de fallback si accountType est absent: le payload est rejeté en 400. Le front doit donc forcer un choix explicite avant submit.

Flows tokenisés

  • tous les flows tokenisés utilisent le champ JSON token
  • le front ne doit plus envoyer inviteToken
  • pour POST /v1/public/structure-adherent-invitations/resolve, la réponse utile est:
  • status
  • nextAction
  • canDecline
  • structureName
  • email
  • expiresAt
  • valeurs possibles de nextAction:
  • signup
  • login
  • unsupported_account
  • none
  • exemples:
{ "token": "..." }

{ "token": "...", "password": "..." }

{ "token": "...", "pseudo": "...", "challengeToken": "..." }

Waitlist admin

GET /v1/web/api/admin/waitlist accepte les filtres existants et le filtre optionnel:

  • accountType=individual
  • accountType=pro

Chaque item de la réponse contient maintenant accountType:

{
  "id": 123,
  "email": "alice@example.com",
  "accountType": "pro",
  "status": 2,
  "createdAt": "2026-04-28T10:00:00Z",
  "city": { "name": "Paris", "postalCode": "75001" },
  "sports": [{ "name": "Tennis" }]
}

Lors du signup depuis une invitation waitlist, le compte créé reprend le accountType stocké sur l'entrée waitlist; le front ne doit pas renvoyer ni recalculer ce type dans le payload d'invitation.

Effets côté front

  • mettre à jour tous les deep links et universal links
  • mettre à jour les route names et écrans associés
  • remplacer les appels GET/POST avec token dans l'URL par des POST JSON
  • nettoyer token de l'URL une fois lu
  • pour structure-adherent-invitation, appeler resolve à l'ouverture puis router l'UI selon nextAction
  • afficher l'action de refus seulement si canDecline=true
  • aligner tous les formulaires sur le champ token