5d3408fafa
Pattern hybride (cf. backend.md §7) : access token Bearer 30min en JSON + refresh token 30j en cookie httpOnly `rubis_refresh` géré custom au-dessus d'@adonisjs/auth qui ne ship pas de primitive refresh.
Migration refresh_tokens (uuid id, user_id FK CASCADE, hashed_token unique [SHA-256, 64 chars hex], expires_at, last_used_at nullable, revoked_at nullable, ip_address, user_agent). Index user_id + expires_at.
Service refresh_token.ts :
- issueRefreshToken(user, ctx) : génère 32 bytes random → base64url → hash SHA-256 stocké, plain dans le cookie httpOnly + secure (en prod) + sameSite strict + path=/api/v1/auth (le browser n'envoie le cookie que sur les routes auth, pas chaque requête API).
- consumeRefreshToken(ctx) : lookup par hash, validation expiry/revoked. Si on présente un token DÉJÀ révoqué, panic mode : tous les refresh tokens actifs du user sont invalidés (signal de vol — le vrai propriétaire devra se re-logger).
- revokeCurrentRefreshToken / revokeAllForUser pour logout et le panic.
Service auth_session.ts : factorise emitAuthSession(user, ctx) qui crée access + refresh + retourne l'AuthSession. Utilisé par signup / login / refresh — DRY.
Controllers :
- POST /auth/signup : emitAuthSession après tx (org + plans + user).
- POST /auth/login : emitAuthSession après verifyCredentials.
- POST /auth/refresh (nouveau) : consumeRefreshToken → emitAuthSession. Rotation : l'ancien token devient révoqué, le nouveau est posé. SPA-side : appelé au boot pour rehydrater + après 401 silencieux.
- POST /account/logout : User.accessTokens.delete + revokeCurrentRefreshToken + clearCookie.
CORS a déjà credentials: true → le cookie traverse cross-origin si origin allowed.
Bruno : nouvelle requête `Auth/04 Refresh.bru` + folder doc + flow décrit dans README. Bruno honore la cookie jar nativement, donc aucun setup additionnel pour tester.
⚠️ Le contrôleur Refresh est nouveau → le registre Tuyau-généré .adonisjs/server/controllers.ts sera régénéré au prochain `pnpm dev:api` (la regen est un effet de bord du boot Adonis, on ne peut pas la déclencher seule). Avant ce premier boot, `pnpm typecheck` échouera sur l'absence de `controllers.Refresh` dans le registre.
67 lines
3.2 KiB
Markdown
67 lines
3.2 KiB
Markdown
# Rubis API — Collection Bruno
|
|
|
|
Collection [Bruno](https://www.usebruno.com/) qui répertorie toutes les routes de l'API et permet de les tester en suivant un parcours réaliste (signup → onboarding → création client → facture → encaissement).
|
|
|
|
## Installation
|
|
|
|
1. Installe Bruno : https://www.usebruno.com/downloads
|
|
2. Dans Bruno, **Open Collection** → sélectionne le dossier `bruno/` à la racine du repo.
|
|
3. Sélectionne l'environnement **local** dans le sélecteur en haut à droite.
|
|
|
|
## Démarrer l'API
|
|
|
|
```bash
|
|
pnpm dev:up # Postgres, Redis, MinIO, Mailpit
|
|
pnpm dev:api # API sur http://localhost:3333
|
|
```
|
|
|
|
Si la DB est neuve : `pnpm -F api exec node ace migration:run`
|
|
|
|
## Variables d'environnement
|
|
|
|
Définies dans `environments/local.bru`. Les valeurs **vides** (token, userId, etc.) sont remplies automatiquement par les `script:post-response` :
|
|
|
|
| Variable | Source | Utilisée par |
|
|
|---|---|---|
|
|
| `baseUrl` | en dur (`http://localhost:3333`) | toutes |
|
|
| `email` / `password` / `fullName` | en dur (login fixture) | Signup, Login |
|
|
| `token` | rempli après Signup/Login | toutes les routes auth |
|
|
| `userId` | rempli après Signup/Login | (info) |
|
|
| `organizationId` | rempli après Signup/Login | (info, debug) |
|
|
| `clientId` | rempli après Create client | détail/update client, création facture |
|
|
| `planSlug` | en dur (`standard-30j`) | détail/update plan |
|
|
| `invoiceId` | rempli après Create invoice OU Validate draft | détail/mark-paid |
|
|
| `batchId` / `draftId` | remplis après Upload (mock) | Get batch / Validate / Skip / Cancel |
|
|
|
|
## Parcours recommandé (premier run)
|
|
|
|
1. **Auth → 01 Signup** (récupère un token + crée l'org + provisionne les 4 plans)
|
|
2. **Account → 01 Get profile** (vérifie l'auth)
|
|
3. **Organizations → 02 Update my org** (onboarding step 2)
|
|
4. **Clients → 04 Create** (crée un client, capture `clientId`)
|
|
5. **Plans → 01 List** (vérifie les 4 plans pré-fournis)
|
|
6. **Invoices → 04 Create** (crée une facture liée au client)
|
|
7. **Invoices → 05 Get detail** (vérifie la timeline)
|
|
8. **Invoices → 06 Mark paid** (encaisse + bonus rubis)
|
|
9. **Organizations → 01 Get my org** (vérifie `rubisCount` incrémenté)
|
|
10. **Clients → 02 List with stats** (vérifie les compteurs)
|
|
11. **Imports → 01 Upload (mock)** (capture `batchId` + `draftId`)
|
|
12. **Imports → 02 Get batch** (review des drafts pending)
|
|
13. **Imports → 03 Validate draft** (transforme le draft en facture)
|
|
|
|
### Flow refresh (silent re-login)
|
|
|
|
Une fois Signup ou Login passé, Bruno a stocké le cookie `rubis_refresh` dans sa cookie jar. Tu peux **vider `token` dans l'env actif** (pour simuler une expiration), puis appeler **Auth → 04 Refresh** : tu reçois un nouveau access token sans devoir re-saisir email/password. C'est ce que le SPA fera silencieusement quand une requête revient en 401.
|
|
|
|
## Reset entre runs
|
|
|
|
L'email `alice@bruno.test` est unique en DB → 2e signup retourne 422 `email_taken`.
|
|
Pour repartir propre :
|
|
|
|
```bash
|
|
docker exec rubis-postgres psql -U rubis -d rubis_dev -c "DROP SCHEMA public CASCADE; CREATE SCHEMA public;"
|
|
pnpm -F api exec node ace migration:run
|
|
```
|
|
|
|
Ou change `email` dans l'environnement local pour forcer un nouveau signup à chaque run.
|