Authentification des membres

Aperçu

Les membres du site sont les utilisateurs finaux de votre site publié - totalement distincts des utilisateurs admin du CMS. Chaque workspace conserve sa propre base de membres (multi-tenant). Le SDK émet les sessions membres sous forme de cookies httpOnly (cmssy_session, un JWE scellé) : le token n'est donc jamais lisible depuis JavaScript et ne touche jamais votre code client. Le SDK gère le scellement, le rafraîchissement et l'échange Authorization: Bearer côté serveur.

1. Configurer

Ajoutez un bloc auth à votre configuration. Il est optionnel - omettez-le et l'auth des membres est simplement désactivée (context.auth vaut undefined et les blocs s'affichent en mode déconnecté).

// cmssy.config.ts
export const cmssy: CmssyNextConfig = {
  // ...
  auth: {
    modelSlug: "members", // the member model in your workspace
    sessionSecret: process.env.CMSSY_SESSION_SECRET!, // >= 32 chars
  },
};

2. Monter la route d'auth

Un seul handler de route pilote tout le flux. Les identifiants et les tokens ne sont traités qu'ici, côté serveur - les clients se contentent d'envoyer des POST.

// app/api/auth/[action]/route.ts
import { createCmssyAuthRoute } from "@cmssy/next";
import { cmssy } from "@/cmssy.config";

export const { POST, GET } = createCmssyAuthRoute(cmssy);

Chaque action renvoie du JSON { ok: boolean, message?, user? }.

3. Rafraîchir les sessions dans le middleware

// middleware.ts
import { createCmssyAuthMiddleware } from "@cmssy/next";
import { cmssy } from "@/cmssy.config";

export const middleware = createCmssyAuthMiddleware(cmssy);

Ceci rafraîchit de manière transparente un cookie de session sur le point d'expirer lors de la navigation, si bien que les membres restent connectés sans aucune gestion de token côté client.

4. Flux d'auth côté client

Vos interfaces de connexion, d'inscription et de déconnexion sont de simples composants clients qui envoient des POST à la route. Ils ne voient jamais de token - la route définit le cookie.

"use client";

// sign in
await fetch("/api/auth/sign-in", {
  method: "POST",
  headers: { "Content-Type": "application/json" },
  body: JSON.stringify({ identity: email, password }),
});
// the route set the cookie - now redirect
window.location.href = "/";

// log out
await fetch("/api/auth/sign-out", { method: "POST" });

Créez des pages dédiées au flux : /login, /register, /forgot-password, /reset-password, /verify-email. Chacune est un petit composant client qui envoie un POST à /api/auth/* puis redirige.

5. Lire le membre courant (côté serveur)

import { getCmssyUser, getCmssyAccessToken } from "@cmssy/next";
import { cmssy } from "@/cmssy.config";

const user = await getCmssyUser(cmssy); // { recordId, email } | null
const token = await getCmssyAccessToken(cmssy); // bearer token | null

6. Lire l'auth dans un bloc

Quand config.auth est défini, createCmssyPage résout le membre côté serveur et l'injecte dans le contexte du bloc sous context.auth - données uniquement :

context.auth;
// { isAuthenticated: boolean; member: { recordId, email } | null } | undefined

import type { CmssyBlockAuthContext } from "@cmssy/react";

function AccountBadge({ context }: { context?: { auth?: CmssyBlockAuthContext } }) {
  if (!context?.auth?.isAuthenticated) return <a href="/login">Sign in</a>;
  return <span>{context.auth.member?.email}</span>;
}

Il n'y a pas de fonctions login/logout sur context.auth - les fonctions ne peuvent pas franchir la frontière serveur-client vers un bloc client. La connexion, la déconnexion et l'inscription passent par les POST clients de l'étape 4.

7. Requêtes membre authentifiées

Une mutation à portée membre (p. ex. la mise à jour d'un profil) a besoin du token d'accès, qui vit dans le cookie httpOnly et est illisible depuis le JS client par conception. N'essayez pas de l'attacher côté client. Appelez-la depuis un handler de route ou une server action qui lit le token et le transmet en Authorization: Bearer :

// app/api/member-graphql/route.ts
import { getCmssyAccessToken } from "@cmssy/next";
import { cmssy } from "@/cmssy.config";

export async function POST(request: Request) {
  const token = await getCmssyAccessToken(cmssy);
  if (!token) {
    return Response.json({ errors: [{ message: "Not authenticated" }] }, { status: 401 });
  }
  const upstream = await fetch(cmssy.apiUrl, {
    method: "POST",
    headers: { "content-type": "application/json", authorization: `Bearer ${token}` },
    body: JSON.stringify(await request.json()),
  });
  return Response.json(await upstream.json(), { status: upstream.status });
}

Votre bloc client envoie alors les mutations membre en POST vers /api/member-graphql au lieu de l'endpoint public, et le token n'atteint jamais le navigateur.

Anti-pattern

// DON'T - XSS-readable, and bypasses the secure cookie flow entirely
localStorage.setItem("member_token", accessToken);

Passez toujours par createCmssyAuthRoute + le cookie httpOnly.

Rôles des membres

Rôles par défaut : Guest, Member (attribué à l'inscription), Premium. Les rôles personnalisés sont configurables par workspace.

Flux de vérification d'e-mail

1. Inscription -> statut pending, un e-mail de vérification est envoyé.
2. Clic sur le lien -> /verify-email?token=... -> statut active.
3. Quand la vérification d'e-mail est requise, la connexion est bloquée tant que le membre n'est pas vérifié.

Flux de réinitialisation du mot de passe

1. Formulaire mot de passe oublié -> un e-mail de réinitialisation est envoyé.
2. Clic sur le lien -> /reset-password?token=... -> définissez un nouveau mot de passe.
3. Les tokens de réinitialisation expirent après 1 heure.

Sessions

La session est un JWE scellé dans le cookie httpOnly cmssy_session. Le middleware le fait tourner de manière transparente à l'approche de l'expiration - votre code ne lit ni ne rafraîchit jamais un token à la main. Toutes les données membres sont limitées au workspace (sûr en multi-tenant).