Utilisateurs, Authentification & Sécurité

Comptes, authentification et modèle de sécurité : comment Chinaski décide qui a le droit de faire quoi, comment les sessions restent réelles, et où chaque action liée à la sécurité est enregistrée. Les pages suivent le parcours de l'opérateur : faire entrer les gens, les délimiter, surveiller la piste.

Dans cette section

• Utilisateurs & Rôles: les deux rôles (admin/editor), la gestion des utilisateurs, la suspension, et l'auto-inscription.
• Authentification: la mécanique de connexion, les lockouts, le modèle de session double (cookie + enregistrement côté serveur), et l'invalidation de session.
• Mots de passe: les règles de mot de passe, l'expiration, les réinitialisations, et ce qu'un changement de mot de passe invalide.
• SSO & OAuth: activer un vrai fournisseur d'identité pour les équipes ; comptes créés depuis les fournisseurs d'identité.
• Permissions: délimiter les éditeurs par types de contenu et langues autorisés, au-delà des deux rôles.
• Modèle de sécurité: les garanties au niveau du code : CSRF partout, secrets hachés au repos, sessions signées, et les règles de confiance pour les en-têtes de proxy.
• Journal d'audit: chaque action de sécurité enregistrée (connexions, verrouillages, changements de contenu), qui a écrit quoi, et la rétention.
• Secrets: ce qui est chiffré et où (credentials stockés, rotation de la clé de signature, le contrat CHINASKI_SECRET de l'env).
• Durcissement: les mesures au niveau du déploiement : contrôles d'upload, honeypots, rate limiting, journal de sécurité externe.
• Mon compte: le libre-service : changements de mot de passe, profil, préférences d'interface, et « log out everywhere ».

Le modèle en un paragraphe

Les gens se connectent avec identifiant + mot de passe (ou un fournisseur SSO quand configuré) et obtiennent une session signée, validée côté serveur ; leurs capacités viennent ensuite de deux niveaux : un rôle (ce qu'ils peuvent atteindre) et des restrictions par utilisateur (quels types de contenu et langues ils gèrent). Chaque issue d'authentification et chaque mutation est enregistrée (une piste d'audit plus des journaux auth/événements séparés) avec des lockouts, une expiration et des rate limits imposés côté serveur. Les secrets (credentials, clés) vivent chiffrés au repos sous une clé dérivée du CHINASKI_SECRET de l'instance, qui est exactement la raison pour laquelle ce fichier env compte autant que les backups.

Ce qui est délibérément simple

• Deux rôles, puis affinage. Il n'y a pas de matrice de rôles par route : editor plus contenus/langues autorisés couvre les besoins réels d'agence ; admin couvre le reste.
• Les sessions sont révocables. Suspendre un utilisateur, réinitialiser un mot de passe, ou « log out everywhere » termine les sessions instantanément, pas à la prochaine reconnexion. L'expiration des mots de passe est imposée au niveau applicatif.
• La piste d'audit est une simple table: assez robuste pour l'analyse forensique de tous les jours, avec une note de durabilité *best-effort* et un journal JSON externe optionnel pour les événements que vous ne pouvez pas vous permettre de perdre.
• L'auto-inscription existe mais est livrée désactivée: l'inscription, les réinitialisations de mot de passe et Turnstile arrivent tous désactivés/optionnels ; les activer est un choix délibéré.