kanbante/docs/porte-centrale.md

Porte centrale unique (0.46.6)

Programme « compte partout / porte centrale unique » : un compte créé au Hub n'a pas de mot de passe local (il vit chez ObsiGate) ; les formulaires locaux des applications ne pourront donc jamais l'accepter. La porte centrale fait de cette réalité le parcours normal : une seule entrée présentée, celle de la suite.

Le réglage

• Nom : porte_centrale (booléen).
• Défaut à la livraison : désactivé. Tant qu'il est inactif, Kanbante se comporte exactement comme avant (formulaire local
  • bouton « Se connecter avec ObsiGate (SSO) »).
• Activation : un administrateur Kanbante le règle dans Administration → Paramètres (ligne porte_centrale : saisir true pour activer, false pour désactiver, vide pour revenir à l'environnement). L'environnement peut aussi amorcer la valeur : KANBANTE_PORTE_CENTRALE=1 — l'environnement amorce, le panneau gouverne, comme les autres réglages surchargeables (app.config.OVERRIDABLE_SETTINGS).

Mode actif

• L'écran de connexion (GET /login) ne présente que l'entrée centrale : le lien « Se connecter avec ObsiGate (SSO) », bien visible, et un texte qui explique qu'il n'y a pas de mot de passe local. Aucun champ identifiant/mot de passe n'est rendu.
• Le formulaire local (POST /login) refuse toute tentative (403), quels que soient les identifiants présentés — mot de passe de base comme repli d'environnement : les identifiants locaux ordinaires ne sont plus acceptés sur cette voie.
• Sessions déjà établies : aucun impact. Le contrôle de session (cookie signé) ne change pas ; une session ouverte avant l'activation reste valide jusqu'à son expiration normale, et le pont draco continue d'en ouvrir par le SSO.
• Non touchés : l'authentification Basic d'environnement (voie scripts historique), les jetons personnels kbt_, le pont /auth/draco et /api/search.

Porte de secours administrateur

Pour ne jamais se verrouiller dehors (panne de l'émettrice, liaison à réparer…), un compte administrateur local désigné peut toujours se connecter — par un chemin discret, jamais proposé ni lié sur l'écran principal :

• Chemin : GET /login/secours (formulaire), POST /login/secours (connexion). Sans configuration, le chemin répond 404, sans explication.
• Désignation, par l'environnement uniquement (secrets — jamais en base, jamais dans le panneau, jamais en dur) :
  • KANBANTE_PORTE_SECOURS_USER : nom du compte administrateur local désigné ;
  • KANBANTE_PORTE_SECOURS_PASSWORD : son mot de passe de secours (comparé en temps constant ; il peut différer du mot de passe de base du compte — c'est un identifiant dédié).
• Gardes : les deux variables doivent être présentes ; le compte désigné doit exister en base, être actif et de rôle admin (ou être l'opérateur d'environnement, administrateur synthétique). Un membre désigné par erreur ne passe pas. L'ouverture de session par cette voie est journalisée (login.porte_secours).
• La session ouverte est une session native ordinaire (7 jours) : l'administrateur peut ensuite désactiver la porte centrale dans le panneau, lier un sub draco, réparer une correspondance, etc.

Fiche d'activation (résumé opérateur)

1. Poser KANBANTE_PORTE_SECOURS_USER et KANBANTE_PORTE_SECOURS_PASSWORD dans l'environnement du conteneur Kanbante, recréer le conteneur.
2. Vérifier la porte de secours : ouvrir /login/secours, se connecter avec le compte désigné.
3. Activer : Administration → Paramètres → porte_centrale = true → Enregistrer.
4. Vérifier : déconnecté, /login ne montre que l'entrée ObsiGate (SSO) ; un essai de formulaire local est refusé ; les sessions déjà ouvertes restent valides.