Tuto 4 : sessions, connection_event, authentification

Un composant d'authentification, un par canal. Au connected, il pose allowMessage de façon synchrone ; au login, il écrit l'identité dans la session ; il re-valide au resumed et libère à l'expired.

Fondé sur : authentification et admission, sessions. Même projet que le tuto 3.

  1. Les clés d'enveloppe id et session

    Le canal serveur pose sur chaque entrant id (identifiant de session, stable à travers les reconnexions) et session (l'objet { data }, joint par référence, jamais cloné). Ce qu'un composant écrit dans session.data, tous les abonnés suivants le lisent. Les deux clés ne partent jamais sur le réseau ; le broker client les ignore.

  2. connection_event

    Contrat fourni par le framework (fw/channel.catalog.js), publié par le canal serveur à quatre moments : connected, resumed, disconnected (la session survit), expired (dernière livraison où la session est lisible).

    connected disconnected expired resumed socket fermé TTL écoulé jeton représenté socket fermé session détruite Cycle de vie d'une session (canal serveur)
    La session survit à une coupure pendant sessionTtlMs. Un client qui revient avec son jeton la reprend (resumed). Un composant libère ce qu'il tenait à l'expired.

  3. Le composant d'auth

    Il filtre connection_event sur payload.channel : un composant d'auth par canal. Au connected, il installe session.allowMessage immédiatement, au minimum un deny-sauf-login, pour qu'aucune trame pipelinée ne passe pendant une fenêtre où la grille serait absente.

  4. Le panneau de connexion côté client

  5. Composer

    Le composant d'auth reçoit le nom d'instance du canal par deps, et une liste de bannis, pour l'exemple.

  6. Voir la porte fonctionner

    Lancez le serveur, ouvrez la page, cliquez sur le bouton avant de vous connecter. Le serveur refuse l'entrant et le dit :

    WARN (channel_plates): message 'click' refusé pour la session 8fa1ee2f-… (allowMessage) — jeté

    Connectez-vous avec « ana » : login_result { granted: true } revient ciblé sur votre seule session, et vos clics passent. Essayez « troll » : refusé.

Admission, pas autorisation fine

allowMessage décide seulement si un message entre dans le broker. Avec le nom et le payload, elle autorise au grain du membre oneOf (par exemple « delete réservé aux admins »). L'autorisation fine d'une action reste au composant qui l'exécute, par une convention libre, hors framework.

Dans le chat, le composant d'auth est gestion_connexion : sa lecture guidée.

← Tuto 3Tuto 5 : faire évoluer un contrat →