HUB-23 — métadonnées des jetons kbt_ pour le registre du Hub (carte fusion #137)
Le Hub (registre des jetons API) a besoin des métadonnées des jetons personnels de Kanbante. Kanbante n'exposait jusqu'ici les jetons qu'en HTML, dans la page Profil du propriétaire. Cette PR ajoute la route de lecture qui manque — rien d'autre.
Authentification : cookie draco_session relayé côté serveur par le Hub — même patron que /api/search (le middleware admet la voie draco pour cette route ; correspondance par utilisateur HUB-16 exigée, aucun JIT ; l'amorçage de l'unique compte admin reste possible, comme sur /api/search).
Portée : un administrateur Kanbante reçoit tous les jetons ; tout autre compte, seulement les siens. Sans cookie valide ou sans correspondance : 401.
Métadonnées seulement : la valeur d'un jeton n'existe plus après sa création, et l'empreinte SHA-256 ne quitte jamais la base — models.list_all_api_tokens() sélectionne explicitement ses colonnes, sans token_hash. Un test vérifie qu'aucune valeur ni empreinte n'apparaît dans la réponse.
Création et révocation inchangées (page Profil de Kanbante) ; le Hub lie vers elle et ne détient rien.
Version et tests
Bump 0.47.0 (fonction, en mineur selon le patron du dépôt) + entrée CHANGELOG.
tests/test_hub_jetons.py : 3 tests verts (401 sans cookie / sans correspondance ; membre limité à ses jetons, états actif/révoqué ; administrateur voyant tous les jetons avec propriétaires ; absence de valeur/empreinte).
Suite complète comparée à main : fonds identiques — 20 échecs préexistants des deux côtés (environnement sans pytest-asyncio ; fonds test_palier*, test_mobile, clients gitea/github), 393 réussis sur main → 396 sur la branche.
Aucune fusion demandée : la fusion reste le geste de Bruno. Tant qu'elle n'est pas faite, l'écran Jetons API du Hub affiche pour Kanbante son état honnête « mise à jour de Kanbante requise (PR en attente) ».
## HUB-23 — métadonnées des jetons `kbt_` pour le registre du Hub (carte fusion #137)
Le Hub (registre des jetons API) a besoin des **métadonnées** des jetons personnels de Kanbante. Kanbante n'exposait jusqu'ici les jetons qu'en HTML, dans la page Profil du propriétaire. Cette PR ajoute la route de lecture qui manque — rien d'autre.
### La route
`GET /api/jetons/metadonnees` → `{ "jetons": [ { "nom", "proprietaire", "prefixe": "kbt_", "cree_le", "dernier_usage", "etat": "actif"|"revoque" } ], "portee": "tous"|"propres" }`
- **Authentification** : cookie `draco_session` relayé côté serveur par le Hub — même patron que `/api/search` (le middleware admet la voie draco pour cette route ; correspondance par utilisateur HUB-16 exigée, **aucun JIT** ; l'amorçage de l'unique compte admin reste possible, comme sur /api/search).
- **Portée** : un **administrateur** Kanbante reçoit tous les jetons ; tout autre compte, seulement les siens. Sans cookie valide ou sans correspondance : 401.
- **Métadonnées seulement** : la valeur d'un jeton n'existe plus après sa création, et l'empreinte SHA-256 ne quitte jamais la base — `models.list_all_api_tokens()` sélectionne explicitement ses colonnes, sans `token_hash`. Un test vérifie qu'aucune valeur ni empreinte n'apparaît dans la réponse.
- Création et révocation **inchangées** (page Profil de Kanbante) ; le Hub lie vers elle et ne détient rien.
### Version et tests
- Bump **0.47.0** (fonction, en mineur selon le patron du dépôt) + entrée CHANGELOG.
- `tests/test_hub_jetons.py` : 3 tests verts (401 sans cookie / sans correspondance ; membre limité à ses jetons, états actif/révoqué ; administrateur voyant tous les jetons avec propriétaires ; absence de valeur/empreinte).
- Tests ciblés relus : `test_hub_jetons` + `test_api_tokens` + `test_draco_correspondance` + `test_agent_journal` = 19 réussis.
- Suite complète comparée à `main` : **fonds identiques** — 20 échecs préexistants des deux côtés (environnement sans pytest-asyncio ; fonds `test_palier*`, `test_mobile`, clients gitea/github), 393 réussis sur main → **396 sur la branche**.
**Aucune fusion demandée** : la fusion reste le geste de Bruno. Tant qu'elle n'est pas faite, l'écran Jetons API du Hub affiche pour Kanbante son état honnête « mise à jour de Kanbante requise (PR en attente) ».
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.
HUB-23 — métadonnées des jetons
kbt_pour le registre du Hub (carte fusion #137)Le Hub (registre des jetons API) a besoin des métadonnées des jetons personnels de Kanbante. Kanbante n'exposait jusqu'ici les jetons qu'en HTML, dans la page Profil du propriétaire. Cette PR ajoute la route de lecture qui manque — rien d'autre.
La route
GET /api/jetons/metadonnees→{ "jetons": [ { "nom", "proprietaire", "prefixe": "kbt_", "cree_le", "dernier_usage", "etat": "actif"|"revoque" } ], "portee": "tous"|"propres" }draco_sessionrelayé côté serveur par le Hub — même patron que/api/search(le middleware admet la voie draco pour cette route ; correspondance par utilisateur HUB-16 exigée, aucun JIT ; l'amorçage de l'unique compte admin reste possible, comme sur /api/search).models.list_all_api_tokens()sélectionne explicitement ses colonnes, sanstoken_hash. Un test vérifie qu'aucune valeur ni empreinte n'apparaît dans la réponse.Version et tests
tests/test_hub_jetons.py: 3 tests verts (401 sans cookie / sans correspondance ; membre limité à ses jetons, états actif/révoqué ; administrateur voyant tous les jetons avec propriétaires ; absence de valeur/empreinte).test_hub_jetons+test_api_tokens+test_draco_correspondance+test_agent_journal= 19 réussis.main: fonds identiques — 20 échecs préexistants des deux côtés (environnement sans pytest-asyncio ; fondstest_palier*,test_mobile, clients gitea/github), 393 réussis sur main → 396 sur la branche.Aucune fusion demandée : la fusion reste le geste de Bruno. Tant qu'elle n'est pas faite, l'écran Jetons API du Hub affiche pour Kanbante son état honnête « mise à jour de Kanbante requise (PR en attente) ».
View command line instructions
Checkout
From your project repository, check out a new branch and test the changes.