Kanbante 0.46.6 — porte centrale unique : réglage administrateur, écran réduit à l'entrée SSO et porte de secours discrète
CI / test (pull_request) Failing after 2m20s
CI / test (push) Failing after 2m54s

This commit is contained in:
Spark
2026-11-07 04:19:08 +00:00
parent f8f8af63e1
commit e4531488d0
9 changed files with 504 additions and 16 deletions
+81
View File
@@ -0,0 +1,81 @@
# 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.