Contexte : spec « Coffre de secrets ObsiGate » §12 (suite). Dépend de la Phase 1. Travail réparti : côté ObsiGate = enregistrement des consommateurs + octrois ; côté chaque app = client de distribution (en branche + PR dans chaque dépôt, jamais merge sans go).
Périmètre :
ObsiGate : enregistrer chaque app comme consommateur nommé, avec jeton propre (jti révocable), distinct du jeton MCP de notes et de la session SSO. Ajouter une app = enregistrer un consommateur + créer des octrois, aucune modification du coffre.
TikTak (prioritaire) : la clé ObsiGate de synchronisation, aujourd'hui en clair par utilisateur dans la configuration de synchro, migre en référence coffre:/. Dans Réglages > Intégrations > ObsiGate, le champ « clé API » devient un sélecteur de référence. TikTak ne stocke que la référence. À chaque synchronisation, le SERVEUR TikTak distribue, utilise, oublie. L'application Android ne voit ni la référence complète ni la valeur. Octroi révoqué => synchro en échec avec « accès révoqué, à ré-accorder dans ObsiGate », sans repli sur une ancienne clé.
Flowdeck : octroi toujours lié à un workspace_id. Un connecteur (Gitea, GitHub, LLM) d'un workspace pointe vers une référence ObsiGate au lieu d'un jeton collé. À l'appel, le serveur Flowdeck distribue en mémoire et ne persiste pas. Un workspace ne peut pas utiliser l'octroi d'un autre, même dans le même coffre. Les secrets déjà chiffrés par Flowdeck peuvent rester en place dans un premier temps ; migration opportuniste, connecteur par connecteur.
Kanbante et autres apps de la suite : même patron, sans variante.
Usages manuels et scripts homelab (dans ObsiGate) : copie manuelle à usage unique avec ré-authentification, valeur copiée au presse-papiers sans affichage, trace distincte copie_manuelle ; client CLI qui distribue et injecte en variable d'environnement du processus enfant (interdits : écriture dans un fichier, affichage, passage en argument de ligne de commande).
Critères d'acceptation :
Synchro TikTak sans clé en clair, sans valeur côté Android.
Isolation workspace Flowdeck démontrée (workspace A ne distribue pas avec l'octroi de B).
Si ObsiGate est indisponible, les consommateurs échouent proprement, sans continuer avec une valeur en cache.
Contexte : spec « Coffre de secrets ObsiGate » §12 (suite). Dépend de la Phase 1. Travail réparti : côté ObsiGate = enregistrement des consommateurs + octrois ; côté chaque app = client de distribution (en branche + PR dans chaque dépôt, jamais merge sans go).
Périmètre :
- ObsiGate : enregistrer chaque app comme consommateur nommé, avec jeton propre (jti révocable), distinct du jeton MCP de notes et de la session SSO. Ajouter une app = enregistrer un consommateur + créer des octrois, aucune modification du coffre.
- TikTak (prioritaire) : la clé ObsiGate de synchronisation, aujourd'hui en clair par utilisateur dans la configuration de synchro, migre en référence coffre:<slug>/<nom>. Dans Réglages > Intégrations > ObsiGate, le champ « clé API » devient un sélecteur de référence. TikTak ne stocke que la référence. À chaque synchronisation, le SERVEUR TikTak distribue, utilise, oublie. L'application Android ne voit ni la référence complète ni la valeur. Octroi révoqué => synchro en échec avec « accès révoqué, à ré-accorder dans ObsiGate », sans repli sur une ancienne clé.
- Flowdeck : octroi toujours lié à un workspace_id. Un connecteur (Gitea, GitHub, LLM) d'un workspace pointe vers une référence ObsiGate au lieu d'un jeton collé. À l'appel, le serveur Flowdeck distribue en mémoire et ne persiste pas. Un workspace ne peut pas utiliser l'octroi d'un autre, même dans le même coffre. Les secrets déjà chiffrés par Flowdeck peuvent rester en place dans un premier temps ; migration opportuniste, connecteur par connecteur.
- Kanbante et autres apps de la suite : même patron, sans variante.
- Usages manuels et scripts homelab (dans ObsiGate) : copie manuelle à usage unique avec ré-authentification, valeur copiée au presse-papiers sans affichage, trace distincte copie_manuelle ; client CLI qui distribue et injecte en variable d'environnement du processus enfant (interdits : écriture dans un fichier, affichage, passage en argument de ligne de commande).
Critères d'acceptation :
- Synchro TikTak sans clé en clair, sans valeur côté Android.
- Isolation workspace Flowdeck démontrée (workspace A ne distribue pas avec l'octroi de B).
- Si ObsiGate est indisponible, les consommateurs échouent proprement, sans continuer avec une valeur en cache.
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.
Contexte : spec « Coffre de secrets ObsiGate » §12 (suite). Dépend de la Phase 1. Travail réparti : côté ObsiGate = enregistrement des consommateurs + octrois ; côté chaque app = client de distribution (en branche + PR dans chaque dépôt, jamais merge sans go).
Périmètre :
Critères d'acceptation :