alreshi/1password-cookies

Cookies de session 1Password

Playbook pour les sessions navigateur authentifiées dont les cookies résident dans 1Password, pas dans git. Lisez ceci avant d'écrire du code de synchronisation, récupération ou injection de cookies. Schéma des éléments, mappage Chrome et dépannage : references/REFERENCE.md.

Cette compétence est un flux de travail cookie-de-session. Ce n'est pas le MCP 1Password Environments (montages .env). Ne stockez pas de JSON de cookie comme variables d'environnement.

Pas terminé tant que

Push (JSON → 1Password)

• Cookies exportés avec Get cookies.txt LOCALEMENT au format JSON (pas Netscape .txt)
• Les fichiers JSON de cookies sont dans gitignore
• op est connecté et le coffre existe
• Élément créé ou mis à jour via --template (jamais de valeurs secrètes sur argv)
• Résumé journalisé (comptes, noms de sections, présence/absence du jeton uniquement)

Récupération (application / environnement agent)

• OP_SERVICE_ACCOUNT_TOKEN provient de l'environnement, jamais codé en dur
• Chaque champ cookie est analysé comme un objet cookie JSON complet, avec repli sur valeur simple
• Les logs montrent les comptes / nom d'hôte / présence du jeton — jamais les valeurs

Injection (navigateur)

• Cookies regroupés par origine ; la page navigue vers cette origine avant setCookie
• sameSite, domain / hostOnly, secure mappés (voir references/REFERENCE.md)
• Les cookies rejetés par Chrome sont ignorés ; la connexion est prouvée sans vider les cookies

Ne pas faire

• Commiter le JSON des cookies, ou coller les valeurs de cookie / jeton / cookieHeader dans le chat
• Mettre des secrets sur argv du processus (op item edit … value=secret)
• Modifier des éléments dont le titre est Service Account Auth Token : …
• Utiliser le MCP 1Password Environments ou les montages .env pour les sessions de cookies
• Journaliser Set-Cookie, Authorization, access_token ou les valeurs des champs
• Traiter un champ cookie comme une simple chaîne quand c'est du JSON (domaine/chemin/expiration doivent survivre)

Architecture

1. L'humain exporte les cookies depuis Chrome avec Get cookies.txt LOCALEMENT sous forme de tableau JSON d'objets cookie.
2. CLI (op item create|edit --template) insère ou met à jour un élément API_CREDENTIAL. Chaque cookie est un champ masqué dont la valeur est le JSON complet de l'objet cookie.
3. Les applications non interactives récupèrent avec @1password/sdk et un jeton de compte de service.
4. L'automatisation du navigateur injecte les cookies par origine, puis éventuellement écrit un jeton d'accès dans localStorage / sessionStorage.

op interactif est pour les humains (et les agents avec une CLI connectée). Le SDK de compte de service est pour les robots et les scrapers.

Checklist nouveau projet

Copiez cette liste et remplissez-la avant d'écrire du code :

- [ ] Nom du coffre
- [ ] Titre de l'élément (pas un élément Service Account Auth Token)
- [ ] Un chemin d'export JSON par origine depuis Get cookies.txt LOCALEMENT (gitignoré)
- [ ] ID de section + libellé par fichier JSON
- [ ] Mappe d'URL d'origine (suffixe de domaine cookie → https://host/)
- [ ] Nom de la variable d'environnement du jeton de compte de service (par défaut OP_SERVICE_ACCOUNT_TOKEN)
- [ ] Titres d'éléments protégés à refuser

Ensuite :

1. Exportez les cookies avec Get cookies.txt LOCALEMENT au format JSON. Ajoutez ces noms de fichiers à gitignore.
2. Poussez avec scripts/sync-cookies.sh (copiez dans le projet ou exécutez depuis ce répertoire de compétence).
3. Copiez scripts/fetch-session.js dans l'application ; définissez OP_VAULT_ID / OP_ITEM_ID à partir de op item get --format json (champs id). Privilégiez l'environnement au codage en dur.
4. Implémentez l'injection en utilisant le mappage dans references/REFERENCE.md. Prouvez la connexion avec URL / titre / « a un formulaire de connexion » — pas en affichant les cookies.

Exporter les cookies

Utilisez l'extension Chrome Get cookies.txt LOCALLY (source). Elle lit les cookies sur l'appareil et ne les envoie pas hors de la machine.

1. Connectez-vous au site dans Chrome (et l'hôte SSO, si la session s'étend sur deux origines).
2. Ouvrez Get cookies.txt LOCALLY sur cet onglet.
3. Réglez Format d'export sur JSON — pas Netscape (.txt) et pas Chaîne d'en-tête.
4. Cliquez sur Exporter pour le site actuel. Utilisez Exporter tous les cookies seulement si nécessaire, puis séparez le fichier par origine.
5. Sauvegardez le .json à côté de la boîte à outils (gitignoré). Ce fichier est l'entrée de scripts/sync-cookies.sh --json.

Répétez sur chaque origine pour laquelle vous avez besoin d'une section 1Password. Les cookies.txt au format Netscape ne sont pas une entrée --json valide.

Push

Nécessite op et python3. Les valeurs passent par un modèle temporaire en mode 0600, puis le modèle est supprimé.

bash scripts/sync-cookies.sh \
  --vault VotreCoffre \
  --title "cookies example.com" \
  --hostname "example.com, sso.example.com" \
  --url https://example.com \
  --json ./example.com.json --section app:example.com \
  --json ./sso.example.com.json --section sso:sso.example.com

--section ID:LIBELLÉ s'applique au précédent --json. S'il est omis, l'ID de section est un slug du nom du fichier et le libellé est le nom du fichier.

--dry-run prévisualise. --include-empty stocke les valeurs vides. --keep-missing conserve les champs de cookie qui ont disparu du JSON.

Si le titre existe déjà, mettez à jour cet élément. Ne créez pas un second élément avec le même titre.

Récupération

Les applications runtime utilisent @1password/sdk, pas op :

1. createClient({ auth: process.env.OP_SERVICE_ACCOUNT_TOKEN, integrationName, integrationVersion })
2. client.items.get(vaultId, itemId)
3. Collectez les champs par sectionId (incluez une section cookies legacy si présente)
4. JSON.parse(field.value) quand cela ressemble à un objet cookie ; sinon { name: field.title, value: raw }
5. Construisez cookieHeader uniquement en mémoire. Renvoyez les comptes dans les logs.

Champs intégrés à lire quand présents : hostname, credential (jeton d'accès), username.

Injection

Pour chaque groupe d'origine : goto(origin) → setCookie(...). Si le lot échoue, définissez les cookies un par un et ignorez les échecs.

Cookies SSO d'abord quand le site redirige via SSO, puis l'origine de l'application, puis les origines restantes. Après que les cookies sont chargés, goto l'origine de l'application et injectez credential dans localStorage / sessionStorage comme access_token quand l'application l'attend.

Sécurité

• Chat et logs : noms, comptes, nom d'hôte, booléens. Jamais les valeurs.
• Masquez les clés correspondant à cookie|access_token|authorization|password|credential|secret|set-cookie|cookieheader|bearer.
• Les éléments de compte de service sont protégés en écriture. Les scripts de synchronisation de cookies et de push de secrets doivent refuser ces titres.
• Le JSON des cookies sur le disque est une session active. Gardez-le gitignoré ; traitez le coffre comme source de vérité après la synchronisation.