Redis pour le diagnostic du TTL des tokens CAPTCHA dans vos workflows QA

Les résultats CAPTCHA ont des fenêtres de validité courtes. En QA, l'enjeu n'est pas de « réutiliser » des tokens, mais de mesurer proprement quand un résultat a été produit, quand il expire et comment votre propre backend réagit aux cas limites. Redis convient bien pour cela : les durées de vie, fenêtres temporelles et corrélations peuvent être journalisées avec précision.

Périmètre : ce guide décrit des schémas de diagnostic et de télémétrie pour vos propres environnements QA, ou des environnements explicitement autorisés. Il sert à mesurer des fenêtres d'expiration et des réactions backend, pas à contourner des protections tierces.

Pourquoi le diagnostic TTL compte en QA

Beaucoup d'équipes ne savent pas pourquoi un test passe à un instant et échoue peu après. La cause est souvent dans le timing :

• le widget a été chargé correctement,
• la tâche CaptchaAI a bien été créée,
• le résultat est bien arrivé,
• mais la vérification backend a eu lieu trop tard ou avec un mauvais contexte.

Redis joue ici un rôle de couche de diagnostic : pour chaque exécution, vous pouvez répondre aux mêmes questions :

• À quel moment le résultat a-t-il été demandé ?
• À quel moment a-t-il été reçu ?
• Quelle était la fenêtre restante avant expiration ?
• Quelle réponse a renvoyée le backend ?

Quelles données stocker dans Redis

En QA, peu de champs suffisent, à condition d'être propres. Documentez les fenêtres temporelles plutôt que de transmettre des résultats à d'autres pages ou contextes.

Exemple : journaliser la durée de vie des tokens dans Redis

from __future__ import annotations

from datetime import datetime, timedelta, timezone
import json
import redis


r = redis.Redis(host="localhost", port=6379, decode_responses=True)


def token_record_key(test_run_id: str) -> str:
    return f"qa:captcha:ttl:{test_run_id}"


def store_ttl_record(*, test_run_id: str, task_id: str, received_token: str, ttl_seconds: int) -> str:
    now = datetime.now(timezone.utc)
    payload = {
        "task_id": task_id,
        "token_preview": received_token[:16],
        "issued_at": now.isoformat(),
        "expires_at": (now + timedelta(seconds=ttl_seconds)).isoformat(),
        "verification_result": "pending",
        "environment": "staging",
    }
    key = token_record_key(test_run_id)
    r.set(key, json.dumps(payload), ex=ttl_seconds)
    return key

Ce schéma est volontairement réduit au diagnostic. Il stocke juste ce qu'il faut pour analyser les exécutions QA et tester les bornes d'expiration de manière reproductible.

Intégrer une tâche CaptchaAI dans une exécution QA

import requests
import time


API_KEY = "YOUR_API_KEY"


def submit_and_poll(page_url: str, sitekey: str) -> tuple[str, str]:
    submit = requests.post(
        "https://ocr.captchaai.com/in.php",
        data={
            "key": API_KEY,
            "method": "userrecaptcha",
            "googlekey": sitekey,
            "pageurl": page_url,
            "json": 1,
        },
        timeout=30,
    )
    submit.raise_for_status()
    submit_json = submit.json()
    if submit_json.get("status") != 1:
        raise RuntimeError(submit_json.get("request", "submit failed"))

    task_id = submit_json["request"]
    for _ in range(30):
        time.sleep(5)
        result = requests.get(
            "https://ocr.captchaai.com/res.php",
            params={"key": API_KEY, "action": "get", "id": task_id, "json": 1},
            timeout=30,
        )
        result.raise_for_status()
        result_json = result.json()
        if result_json.get("status") == 1:
            return task_id, result_json["request"]

    raise TimeoutError("CaptchaAI polling timed out")

À l'étape suivante, vous documentez le résultat non comme un objet de cache générique, mais comme un point de mesure QA avec une borne d'expiration claire.

Vérifier les bornes d'expiration contre votre backend

Un test QA pertinent comporte souvent deux passages :

1. vérification immédiate après réception du résultat,
2. vérification volontairement retardée juste avant ou juste après la borne d'expiration interne.

def verify_in_staging(token: str, test_run_id: str, delay_seconds: int = 0) -> dict:
    if delay_seconds:
        time.sleep(delay_seconds)

    response = requests.post(
        "https://staging.example-app.test/qa/captcha/verify",
        json={
            "token": token,
            "testRunId": test_run_id,
            "environment": "staging",
        },
        timeout=30,
    )
    response.raise_for_status()
    return response.json()

Vous voyez ainsi si votre backend rejette correctement les résultats expirés ou tardifs et si les codes d'erreur remontent proprement dans le monitoring.

Dépannage

Guides connexes sûrs

• Démarrage rapide CaptchaAI
• Tests QA CAPTCHA dans des environnements autorisés
• Tester les endpoints CAPTCHA dans vos formulaires web
• Intégration continue avec des tests CAPTCHA

Documentez les bornes d'expiration et les réactions backend avec des données QA fiables — CaptchaAI facilite des exécutions de vérification reproductibles dans vos propres environnements.