Tutorials

Charger vos clés CaptchaAI avec le CLI 1Password en dev local

Périmètre sûr : ce guide couvre vos propres applications et les environnements pour lesquels vous détenez une autorisation écrite.

Une clé API CaptchaAI écrite en clair dans un .env atterrit un jour là où elle n'a rien à faire : un commit, une capture d'écran, un runner partagé. La parade tient en trois mouvements :

  1. Rangez la clé dans un coffre 1Password partagé avec l'équipe.
  2. Référencez-la par une chaîne op:// dans un .env.template versionné sans risque.
  3. Lancez vos scripts avec op run : la valeur n'existe que le temps du processus.

Pourquoi le .env local est le maillon faible

Le .env a un défaut structurel : il est pratique. On le duplique, on l'oublie dans une sauvegarde. Prenez une équipe de quatre développeurs à Lyon sur le plan ADVANCE ($90/mois, 50 threads) : sans coffre, la clé circule sur quatre machines et la révoquer bloque tout le monde. Avec 1Password, elle vit à un seul endroit et la rotation tient en un champ.

Étape 1 : ranger la clé dans un coffre dédié

Créez un coffre distinct de votre coffre personnel, puis un élément et un champ dédiés à la clé. Leurs noms, assemblés en une référence op://, sont ce que vous manipulerez partout — jamais la clé. Validez la référence avec op read.

Ce que vous créez Exemple Ce que le code voit
Coffre d'équipe Dev rien
Élément CaptchaAI rien
Champ secret api_key op://Dev/CaptchaAI/api_key

Étape 2 : injecter la clé à l'exécution avec op run

Créez un .env.template qui contient la référence plutôt que la valeur : CAPTCHAAI_KEY=op://Dev/CaptchaAI/api_key. Ce fichier-là se commite sans risque : il documente les variables attendues, pas leurs valeurs. Lancez ensuite vos scripts via op run --env-file=.env.template -- python solve.py : le CLI injecte les valeurs dans le processus enfant, puis les oublie. Rien sur le disque, rien dans l'historique du shell.

Étape 3 : lire la variable dans le code d'appel

Côté code, rien ne change : vous lisez une variable d'environnement ordinaire. Aucune dépendance à 1Password n'entre dans l'application, seul le mode de lancement change.

import fetch from 'node-fetch';

const API_KEY = process.env.CAPTCHAAI_KEY;

export async function createTurnstileTask(siteKey, pageUrl) {
  const res = await fetch('https://api.captchaai.com/createTask', {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({
      clientKey: API_KEY,
      task: {
        type: 'TurnstileTaskProxyless',
        websiteURL: pageUrl,
        websiteKey: siteKey,
      },
    }),
  });
  const data = await res.json();
  return data.taskId;
}

Encapsulez cet appel dans une fonction unique qui trace durée et code retour : un seul endroit à corriger si le type de CAPTCHA change.

Vérifier le token côté backend

Validez le token dans votre propre backend avant toute opération métier : aucune requête ne doit passer sur la foi d'un token périmé ou fabriqué. Appliquez-le dans la session qui a déclenché le défi CAPTCHA — même navigateur, mêmes cookies. Le décalage de session reste la première cause de rejet.

Journaliser sans réexposer le secret

Le piège est connu : trois étapes de protection, puis un print de débogage recrache la clé dans les logs. La règle est simple :

  • À tracer : durée d'obtention du token, code HTTP, identifiant de tâche.
  • À ne jamais tracer : l'en-tête d'authentification, la valeur de CAPTCHAAI_KEY, la sortie brute de op read.

Cette hygiène rejoint vos obligations RGPD : moins vos journaux contiennent de données sensibles, moins leur conservation soulève de questions.

Dépannage

Symptôme Cause probable Correctif
Variable vide malgré op run Champ inexistant dans l'élément Vérifiez le champ avec op item get CaptchaAI
Erreur d'authentification au lancement Session op expirée ou coffre non partagé Relancez op signin et vérifiez les droits
Token refusé après résolution correcte Token appliqué dans une autre session Rejouez dans le même contexte HTTP

Liste de contrôle avant le premier commit

  • Seul .env.template est versionné, avec des références op:// uniquement.
  • Le coffre est partagé, jamais la valeur de la clé.
  • Tous les scripts se lancent par op run.

FAQ

Comment partager la clé CaptchaAI entre plusieurs développeurs ?

Partagez le coffre, jamais la valeur. Un départ se règle en retirant un accès, pas en régénérant la clé de toute l'équipe.

Que faire si op run ne résout pas la référence ?

Testez la référence avec op read : neuf fois sur dix, le nom du coffre ou du champ diffère d'une majuscule. Sinon, la session a expiré.

La méthode fonctionne-t-elle aussi en intégration continue ?

Oui, mais l'authentification change : en CI, vous passez par un token de service et le magasin de secrets du fournisseur. .env.template reste identique, le code ne voit aucune différence.

Comment révoquer une clé compromise ?

Générez-en une nouvelle dans le tableau de bord CaptchaAI, remplacez le champ dans 1Password, relancez vos processus : aucune copie locale ne traîne.

Guides connexes

Une clé bien rangée, c'est un incident de moins. – Obtenez votre clé CaptchaAI.

Les commentaires sont désactivés pour cet article.