Authentification & autorisation

L'authentification repose sur Better Auth, branché sur la base via l'adaptateur Drizzle (schéma apps/server/src/db/schema/auth.ts). Deux méthodes sont activées : e-mail et mot de passe, et OAuth Microsoft.

Configuration serveur

apps/server/src/lib/auth.ts :

Le handler est monté dans apps/server/src/index.ts :

app.on(["POST", "GET"], "/api/auth/**", (c) => auth.handler(c.req.raw));

Les routes sont donc POST /api/auth/sign-in/email, GET /api/auth/callback/microsoft (chemin par défaut de Better Auth), etc.

Réinitialisation du mot de passe

Aucun envoi d'e-mail n'est configuré (lib/auth.ts ne définit ni sendResetPassword, ni sendVerificationEmail) : il n'y a donc pas de réinitialisation par e-mail, et les pages correspondantes ont été retirées du web.

Contrôle d'accès des procédures

Les procédures oRPC (apps/server/src/lib/orpc.ts) appliquent trois niveaux :

createContext() récupère la session à chaque requête RPC. Les procédures protégées mettent à jour user.last_connection.

Le contrôle admin porte sur le champ user.role de Better Auth, et non sur la table roles. Un rôle applicatif (choix de l'index, voir Rôles & tags) ne donne pas de droits admin, sauf s'il s'appelle admin.

Côté web

apps/web/src/lib/auth-client.ts crée le client avec baseURL: getServerUrl(), c'est-à-dire la valeur de VITE_SERVER_URL sans suffixe. Better Auth ajoute le chemin /api/auth. Si VITE_SERVER_URL contient déjà /api/auth, le chemin est doublé et les appels échouent.

Les appels oRPC envoient les cookies (credentials: 'include'). Le front et le serveur doivent donc partager une origine autorisée par CORS_ORIGIN.

Dépannage