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 :
- Rangez la clé dans un coffre 1Password partagé avec l'équipe.
- Référencez-la par une chaîne
op://dans un.env.templateversionné sans risque. - 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 deop 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.templateest versionné, avec des référencesop://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
- le démarrage rapide CaptchaAI
- la QA CAPTCHA en environnement autorisé
- tester l'endpoint API
- la résolution CAPTCHA en CI
- résoudre reCAPTCHA v2 via l'API
Une clé bien rangée, c'est un incident de moins. – Obtenez votre clé CaptchaAI.