Carte : Projets/fusion-trois-apps#129 — HUB-15 (plan Hub v2.1, §2.2 mécanisme 2 et §4). Aucune fusion sans l'ordre de Bruno.
Comportement avant / après
Avant : maybe_link liait le compte local au sub draco quand session native et cookie draco coexistaient ; le pont GET /auth/draco résolvait le sub via draco_links, avec repli mono-utilisateur. En multi-utilisateurs, un sub sans lien était refusé (retour à la connexion locale) : un compte de suite créé dans le Hub ne « fonctionnait » pas dans Flowdeck sans création/liaison manuelle préalable.
Après : généralisation en provisionnement JIT (app/services/draco.py, user_for_draco) — lier si un compte local correspond, créer sinon :
lien draco_links actif → compte lié (inchangé) ;
repli mono-utilisateur existant (inchangé) ;
sinon, création automatique du pendant local depuis les claims (sub, name) + liaison, dans la même transaction.
Rôle par défaut et sécurité
Utilisateur standard (is_admin = 0, jamais admin), is_active = 1, auth_method = 'draco'.
Aucun mot de passe local : password_hash NULL (patron des comptes OAuth existants) — la connexion locale par mot de passe est impossible pour ce compte et inchangée pour tous les autres comptes ; l'OAuth Gitea/GitHub n'est pas touché.
Login déterministe draco-<sub> (suffixe d'empreinte courte si ce login est déjà pris par un compte non lié — jamais de liaison ni d'écrasement d'un compte existant).
Garde pierre tombale : s'il existe une ligne draco_links pour ce sub (lien actif, compte inactif, ou dissociation explicite), aucune création — une dissociation n'est jamais contournée automatiquement ; la ré-association explicite existante (POST /auth/draco-link) reste la voie de retour.
Comptes déjà liés
Rien ne change : liens existants, repli mono-utilisateur, sessions, connexion locale et OAuth se comportent exactement comme avant. La création ne se déclenche que pour un sub valide, non révoqué, sans aucune ligne draco_links.
Version
7.85.0 — fonction nouvelle : série mineure du dépôt (7.84 → 7.85 ; la série porte les vagues de fonctions, les correctifs restent en patch).
Tests (lus, comparés au fonds sur main vierge, même environnement)
tests/test_fusion_draco.py : 9/9 (fonds 7/7) — 2 nouveaux tests JIT (création en multi-utilisateurs : rôle, password_hash NULL, lien, réutilisation à la 2e visite, connexion locale refusée en 401 ; pierre tombale sans re-création) et l'ancien refus « lien requis en multi-utilisateurs » remplacé par le nouveau contrat (le lien explicite continue d'ouvrir la porte).
Balayage auth élargi (-k "auth or sso or oauth or draco or session or login or scim", incl. test_v67_sso.py, test_fusion_tiktak.py, test_pwa_offline.py) : 226 réussis (fonds 224) ; 3 échecs préexistants identiques sur main vierge (test_v756_oauth_connectors ×2, test_v757_mcp_discord ×1 — accès réseau).
Carte : `Projets/fusion-trois-apps` **#129 — HUB-15** (plan Hub v2.1, §2.2 mécanisme 2 et §4). **Aucune fusion sans l'ordre de Bruno.**
## Comportement avant / après
**Avant** : `maybe_link` liait le compte local au `sub` draco quand session native et cookie draco coexistaient ; le pont `GET /auth/draco` résolvait le `sub` via `draco_links`, avec repli mono-utilisateur. En multi-utilisateurs, un `sub` sans lien était **refusé** (retour à la connexion locale) : un compte de suite créé dans le Hub ne « fonctionnait » pas dans Flowdeck sans création/liaison manuelle préalable.
**Après** : généralisation en **provisionnement JIT** (`app/services/draco.py`, `user_for_draco`) — lier si un compte local correspond, **créer sinon** :
1. lien `draco_links` actif → compte lié (inchangé) ;
2. repli mono-utilisateur existant (inchangé) ;
3. sinon, **création automatique du pendant local** depuis les claims (`sub`, `name`) + liaison, dans la même transaction.
## Rôle par défaut et sécurité
- Utilisateur **standard** (`is_admin = 0`, **jamais admin**), `is_active = 1`, `auth_method = 'draco'`.
- **Aucun mot de passe local** : `password_hash` NULL (patron des comptes OAuth existants) — la connexion locale par mot de passe est impossible pour ce compte et **inchangée pour tous les autres comptes** ; l'OAuth Gitea/GitHub n'est pas touché.
- Login déterministe `draco-<sub>` (suffixe d'empreinte courte si ce login est déjà pris par un compte non lié — jamais de liaison ni d'écrasement d'un compte existant).
- **Garde pierre tombale** : s'il existe une ligne `draco_links` pour ce `sub` (lien actif, compte inactif, ou dissociation explicite), aucune création — une dissociation n'est jamais contournée automatiquement ; la ré-association explicite existante (`POST /auth/draco-link`) reste la voie de retour.
## Comptes déjà liés
**Rien ne change** : liens existants, repli mono-utilisateur, sessions, connexion locale et OAuth se comportent exactement comme avant. La création ne se déclenche que pour un `sub` valide, non révoqué, sans aucune ligne `draco_links`.
## Version
**7.85.0** — fonction nouvelle : série mineure du dépôt (7.84 → 7.85 ; la série porte les vagues de fonctions, les correctifs restent en patch).
## Tests (lus, comparés au fonds sur main vierge, même environnement)
- `tests/test_fusion_draco.py` : **9/9** (fonds 7/7) — 2 nouveaux tests JIT (création en multi-utilisateurs : rôle, `password_hash` NULL, lien, réutilisation à la 2e visite, connexion locale refusée en 401 ; pierre tombale sans re-création) et l'ancien refus « lien requis en multi-utilisateurs » remplacé par le nouveau contrat (le lien explicite continue d'ouvrir la porte).
- Balayage auth élargi (`-k "auth or sso or oauth or draco or session or login or scim"`, incl. `test_v67_sso.py`, `test_fusion_tiktak.py`, `test_pwa_offline.py`) : **226 réussis** (fonds 224) ; 3 échecs **préexistants identiques sur main vierge** (`test_v756_oauth_connectors` ×2, `test_v757_mcp_discord` ×1 — accès réseau).
Généralisation de maybe_link : à la première connexion draco, si
aucun compte local ne correspond au sub (ni lien draco_links, ni
repli mono-utilisateur), le pendant local est créé depuis les
claims (sub, name) et lié dans la même transaction. Rôle par
défaut sûr : utilisateur standard (is_admin=0), auth_method
'draco', password_hash NULL (aucune connexion locale par mot de
passe pour ce compte ; inchangée pour les autres). Garde pierre
tombale : une ligne draco_links existante interdit toute création.
Connexion locale et OAuth Gitea/GitHub intacts.
Tests : test_fusion_draco.py étendu (création JIT, pierre
tombale) ; 9/9 sur le fichier, balayage auth 226 réussis
(3 échecs préexistants sur main vierge, réseau).
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Carte :
Projets/fusion-trois-apps#129 — HUB-15 (plan Hub v2.1, §2.2 mécanisme 2 et §4). Aucune fusion sans l'ordre de Bruno.Comportement avant / après
Avant :
maybe_linkliait le compte local ausubdraco quand session native et cookie draco coexistaient ; le pontGET /auth/dracorésolvait lesubviadraco_links, avec repli mono-utilisateur. En multi-utilisateurs, unsubsans lien était refusé (retour à la connexion locale) : un compte de suite créé dans le Hub ne « fonctionnait » pas dans Flowdeck sans création/liaison manuelle préalable.Après : généralisation en provisionnement JIT (
app/services/draco.py,user_for_draco) — lier si un compte local correspond, créer sinon :draco_linksactif → compte lié (inchangé) ;sub,name) + liaison, dans la même transaction.Rôle par défaut et sécurité
is_admin = 0, jamais admin),is_active = 1,auth_method = 'draco'.password_hashNULL (patron des comptes OAuth existants) — la connexion locale par mot de passe est impossible pour ce compte et inchangée pour tous les autres comptes ; l'OAuth Gitea/GitHub n'est pas touché.draco-<sub>(suffixe d'empreinte courte si ce login est déjà pris par un compte non lié — jamais de liaison ni d'écrasement d'un compte existant).draco_linkspour cesub(lien actif, compte inactif, ou dissociation explicite), aucune création — une dissociation n'est jamais contournée automatiquement ; la ré-association explicite existante (POST /auth/draco-link) reste la voie de retour.Comptes déjà liés
Rien ne change : liens existants, repli mono-utilisateur, sessions, connexion locale et OAuth se comportent exactement comme avant. La création ne se déclenche que pour un
subvalide, non révoqué, sans aucune lignedraco_links.Version
7.85.0 — fonction nouvelle : série mineure du dépôt (7.84 → 7.85 ; la série porte les vagues de fonctions, les correctifs restent en patch).
Tests (lus, comparés au fonds sur main vierge, même environnement)
tests/test_fusion_draco.py: 9/9 (fonds 7/7) — 2 nouveaux tests JIT (création en multi-utilisateurs : rôle,password_hashNULL, lien, réutilisation à la 2e visite, connexion locale refusée en 401 ; pierre tombale sans re-création) et l'ancien refus « lien requis en multi-utilisateurs » remplacé par le nouveau contrat (le lien explicite continue d'ouvrir la porte).-k "auth or sso or oauth or draco or session or login or scim", incl.test_v67_sso.py,test_fusion_tiktak.py,test_pwa_offline.py) : 226 réussis (fonds 224) ; 3 échecs préexistants identiques sur main vierge (test_v756_oauth_connectors×2,test_v757_mcp_discord×1 — accès réseau).