Ne pas merger sans le go du coordinateur ; aucune version bumpée, aucune issue fermée ou rouverte par cette PR (les issues Projets/fusion-trois-apps #68 et #69 restent les suites de validation, leur état est inchangé).
Matrice constatée par Bruno (2026-10-28 13:33 EDT, page /recherche)
Depuis TikTak : ObsiGate OK ; Flowdeck ÉCHEC ; Kanbante ÉCHEC. Depuis Kanbante : ObsiGate OK ; Flowdeck ÉCHEC ; TikTak ÉCHEC. Depuis Flowdeck : ObsiGate OK, Flowdeck OK (lui-même) ; TikTak ÉCHEC ; Kanbante ÉCHEC. Depuis ObsiGate : ObsiGate OK ; Flowdeck ÉCHEC ; TikTak OK ; Kanbante OK. Le message affiché est « Injoignable depuis cet hôte (CORS ou réseau) » (fetch sans statut : blocage CORS/CSP/réseau, pas un 401/403).
Audit (vérifié sur main, dans le code)
Kanbante n'autorisait que l'environnement résolu (app/config.resoudre_urls_draco, hôte Host d'abord — derrière un tunnel, un hôte interne fait retomber la résolution sur la configuration) — prod OU dev, jamais les deux. Une page de l'autre environnement voyait donc sa section refusée.
Même schéma mono-environnement chez les sœurs : TikTak (draco_urls(hote_depuis_requete)), Flowdeck (draco_urls.toutes() configuration seule au moment du middleware CORS, plus l'environnement de l'hôte de la requête ; alertes via le CORSMiddleware global figé à l'import), ObsiGate (urls_publiques(), configuration seule).
La CSP connect-src n'est PAS le verrou : Kanbante n'énonce que frame-src (pas de connect-src à ouvrir), et les pages des autres hôtes résolvent leurs sœurs dans leur propre environnement. Cette PR ne touche donc à aucune CSP.
Le cross-origin authentifié fonctionne en principe (depuis ObsiGate, TikTak et Kanbante répondent) : aucun repli serveur (proxy fan-out) n'est implémenté, conformément au chantier.
Ce que le code ne permet pas de conclure (à valider déployé) : la configuration réelle déclarée par chaque instance (.env dev/prod), et un éventuel filtre Cloudflare Access devant une instance — ni l'un ni l'autre ne sont visibles dans le code.
Ce qui change (Kanbante)
app/recherche.py : sister_origins() retourne désormais les origines résolues plusPROD_ORIGINS | DEV_ORIGINS — les 8 origines officielles (og, flowdeck, tiktak, kanbante, avec et sans -dev, en https://*.dracodev.net), listées explicitement, jamais *, avec Access-Control-Allow-Credentials: true. Une origine inconnue reste refusée.
app/main.py (DracoAlertesCorsMiddleware) : même union pour GET /api/events (fusion #69).
Tests : tests/test_recherche.py (allowlist = 8 origines quelle que soit la résolution ; autre environnement autorisé ; tiers et sosie refusés) et tests/test_draco_alertes.py (preflight depuis une origine dev autorisé, tiers refusé).
Non touchés : pages /recherche et alertes, ligne d'onglets de la barre, versions, état des issues.
Tests (chiffres réels, exécutés le 2026-10-28)
Module app/recherche.py chargé par chemin + middleware ASGI simulé : 8 origines, preflight prod 204 / dev 204 / tiers transmis sans en-tête — OK.
Fichier tests/test_recherche.py rejoué hors pytest (pytest absent de la sandbox) : 8 tests OK (dont les cas mis à jour).
python3 -m py_compile sur app/recherche.py, app/main.py, les 2 fichiers de tests : OK.
Non exécutés ici (dépendances applicatives absentes de la sandbox) : pytest tests/test_recherche.py tests/test_draco_alertes.py et le serveur — à valider en CI / après déploiement.
Validation déployée restante (par Bruno)
Matrice 4 hôtes × 4 sections sur /recherche (dev et prod) + panneau Alertes unifiées depuis chaque hôte : chaque section sœur doit afficher des résultats (ou « vide »), plus jamais « Injoignable ». Cas négatif à garder : une origine tierce ne doit toujours recevoir aucun en-tête Access-Control-Allow-Origin.
## CORS recherche/alertes : allowlist sœurs prod+dev explicites (fusion #68/#69, chantier 1)
Ne pas merger sans le go du coordinateur ; aucune version bumpée, aucune issue fermée ou rouverte par cette PR (les issues Projets/fusion-trois-apps #68 et #69 restent les suites de validation, leur état est inchangé).
### Matrice constatée par Bruno (2026-10-28 13:33 EDT, page /recherche)
Depuis TikTak : ObsiGate OK ; Flowdeck ÉCHEC ; Kanbante ÉCHEC. Depuis Kanbante : ObsiGate OK ; Flowdeck ÉCHEC ; TikTak ÉCHEC. Depuis Flowdeck : ObsiGate OK, Flowdeck OK (lui-même) ; TikTak ÉCHEC ; Kanbante ÉCHEC. Depuis ObsiGate : ObsiGate OK ; Flowdeck ÉCHEC ; TikTak OK ; Kanbante OK. Le message affiché est « Injoignable depuis cet hôte (CORS ou réseau) » (fetch sans statut : blocage CORS/CSP/réseau, pas un 401/403).
### Audit (vérifié sur main, dans le code)
- Kanbante n'autorisait que l'environnement résolu (`app/config.resoudre_urls_draco`, hôte `Host` d'abord — derrière un tunnel, un hôte interne fait retomber la résolution sur la configuration) — prod OU dev, jamais les deux. Une page de l'autre environnement voyait donc sa section refusée.
- Même schéma mono-environnement chez les sœurs : TikTak (`draco_urls(hote_depuis_requete)`), Flowdeck (`draco_urls.toutes()` configuration seule au moment du middleware CORS, plus l'environnement de l'hôte de la requête ; alertes via le `CORSMiddleware` global figé à l'import), ObsiGate (`urls_publiques()`, configuration seule).
- La CSP `connect-src` n'est PAS le verrou : Kanbante n'énonce que `frame-src` (pas de `connect-src` à ouvrir), et les pages des autres hôtes résolvent leurs sœurs dans leur propre environnement. Cette PR ne touche donc à aucune CSP.
- Le cross-origin authentifié fonctionne en principe (depuis ObsiGate, TikTak et Kanbante répondent) : aucun repli serveur (proxy fan-out) n'est implémenté, conformément au chantier.
- Ce que le code ne permet pas de conclure (à valider déployé) : la configuration réelle déclarée par chaque instance (`.env` dev/prod), et un éventuel filtre Cloudflare Access devant une instance — ni l'un ni l'autre ne sont visibles dans le code.
### Ce qui change (Kanbante)
- `app/recherche.py` : `sister_origins()` retourne désormais les origines résolues **plus** `PROD_ORIGINS | DEV_ORIGINS` — les 8 origines officielles (`og`, `flowdeck`, `tiktak`, `kanbante`, avec et sans `-dev`, en `https://*.dracodev.net`), listées explicitement, jamais `*`, avec `Access-Control-Allow-Credentials: true`. Une origine inconnue reste refusée.
- `app/main.py` (`DracoAlertesCorsMiddleware`) : même union pour `GET /api/events` (fusion #69).
- Tests : `tests/test_recherche.py` (allowlist = 8 origines quelle que soit la résolution ; autre environnement autorisé ; tiers et sosie refusés) et `tests/test_draco_alertes.py` (preflight depuis une origine dev autorisé, tiers refusé).
- Non touchés : pages `/recherche` et alertes, ligne d'onglets de la barre, versions, état des issues.
### Tests (chiffres réels, exécutés le 2026-10-28)
- Module `app/recherche.py` chargé par chemin + middleware ASGI simulé : 8 origines, preflight prod 204 / dev 204 / tiers transmis sans en-tête — OK.
- Fichier `tests/test_recherche.py` rejoué hors pytest (pytest absent de la sandbox) : **8 tests OK** (dont les cas mis à jour).
- `python3 -m py_compile` sur `app/recherche.py`, `app/main.py`, les 2 fichiers de tests : OK.
- Non exécutés ici (dépendances applicatives absentes de la sandbox) : `pytest tests/test_recherche.py tests/test_draco_alertes.py` et le serveur — à valider en CI / après déploiement.
### Validation déployée restante (par Bruno)
Matrice 4 hôtes × 4 sections sur `/recherche` (dev et prod) + panneau Alertes unifiées depuis chaque hôte : chaque section sœur doit afficher des résultats (ou « vide »), plus jamais « Injoignable ». Cas négatif à garder : une origine tierce ne doit toujours recevoir aucun en-tête `Access-Control-Allow-Origin`.
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.
CORS recherche/alertes : allowlist sœurs prod+dev explicites (fusion #68/#69, chantier 1)
Ne pas merger sans le go du coordinateur ; aucune version bumpée, aucune issue fermée ou rouverte par cette PR (les issues Projets/fusion-trois-apps #68 et #69 restent les suites de validation, leur état est inchangé).
Matrice constatée par Bruno (2026-10-28 13:33 EDT, page /recherche)
Depuis TikTak : ObsiGate OK ; Flowdeck ÉCHEC ; Kanbante ÉCHEC. Depuis Kanbante : ObsiGate OK ; Flowdeck ÉCHEC ; TikTak ÉCHEC. Depuis Flowdeck : ObsiGate OK, Flowdeck OK (lui-même) ; TikTak ÉCHEC ; Kanbante ÉCHEC. Depuis ObsiGate : ObsiGate OK ; Flowdeck ÉCHEC ; TikTak OK ; Kanbante OK. Le message affiché est « Injoignable depuis cet hôte (CORS ou réseau) » (fetch sans statut : blocage CORS/CSP/réseau, pas un 401/403).
Audit (vérifié sur main, dans le code)
app/config.resoudre_urls_draco, hôteHostd'abord — derrière un tunnel, un hôte interne fait retomber la résolution sur la configuration) — prod OU dev, jamais les deux. Une page de l'autre environnement voyait donc sa section refusée.draco_urls(hote_depuis_requete)), Flowdeck (draco_urls.toutes()configuration seule au moment du middleware CORS, plus l'environnement de l'hôte de la requête ; alertes via leCORSMiddlewareglobal figé à l'import), ObsiGate (urls_publiques(), configuration seule).connect-srcn'est PAS le verrou : Kanbante n'énonce queframe-src(pas deconnect-srcà ouvrir), et les pages des autres hôtes résolvent leurs sœurs dans leur propre environnement. Cette PR ne touche donc à aucune CSP..envdev/prod), et un éventuel filtre Cloudflare Access devant une instance — ni l'un ni l'autre ne sont visibles dans le code.Ce qui change (Kanbante)
app/recherche.py:sister_origins()retourne désormais les origines résolues plusPROD_ORIGINS | DEV_ORIGINS— les 8 origines officielles (og,flowdeck,tiktak,kanbante, avec et sans-dev, enhttps://*.dracodev.net), listées explicitement, jamais*, avecAccess-Control-Allow-Credentials: true. Une origine inconnue reste refusée.app/main.py(DracoAlertesCorsMiddleware) : même union pourGET /api/events(fusion #69).tests/test_recherche.py(allowlist = 8 origines quelle que soit la résolution ; autre environnement autorisé ; tiers et sosie refusés) ettests/test_draco_alertes.py(preflight depuis une origine dev autorisé, tiers refusé)./rechercheet alertes, ligne d'onglets de la barre, versions, état des issues.Tests (chiffres réels, exécutés le 2026-10-28)
app/recherche.pychargé par chemin + middleware ASGI simulé : 8 origines, preflight prod 204 / dev 204 / tiers transmis sans en-tête — OK.tests/test_recherche.pyrejoué hors pytest (pytest absent de la sandbox) : 8 tests OK (dont les cas mis à jour).python3 -m py_compilesurapp/recherche.py,app/main.py, les 2 fichiers de tests : OK.pytest tests/test_recherche.py tests/test_draco_alertes.pyet le serveur — à valider en CI / après déploiement.Validation déployée restante (par Bruno)
Matrice 4 hôtes × 4 sections sur
/recherche(dev et prod) + panneau Alertes unifiées depuis chaque hôte : chaque section sœur doit afficher des résultats (ou « vide »), plus jamais « Injoignable ». Cas négatif à garder : une origine tierce ne doit toujours recevoir aucun en-têteAccess-Control-Allow-Origin.