Conserver les cookies de l’application lors de l’envoi d’un jeton résolu

Utilisez Python 3.10+ avec requests et le SDK Python officiel solvethree installés. Le nom d’hôte cible doit disposer d’un profil actif dans votre espace de travail ; envoyer son nom d’hôte dans une tâche n’en crée pas. Consultez la configuration d’un profil de site s’il n’est pas configuré.

• Définissez TARGET_URL sur l’URL du formulaire de votre application. Cette démonstration sur un site que vous contrôlez utilise la même URL pour le GET et le POST.
• Définissez SOLVETHREE_PROXY sur le proxy unique utilisé pour la résolution et les deux requêtes de l’application.
• Définissez SOLVETHREE_API_KEY sur la clé API de votre espace de travail. Exécutez ce code côté serveur.

# This owned demo form has an input named csrf_token and g-recaptcha-response.
import os
from html.parser import HTMLParser
from urllib.parse import urlsplit
import requests
from solvethree import Solvethree

class FormParser(HTMLParser):
    csrf = None
    def handle_starttag(self, tag, attributes):
        values = dict(attributes)
        if tag == "input" and values.get("name") == "csrf_token":
            self.csrf = values.get("value")

target = os.environ["TARGET_URL"]
proxy = os.environ["SOLVETHREE_PROXY"]
request = {"site": urlsplit(target).hostname, "action": "login", "proxy": proxy}
# Obtain the solver's browser headers before opening the application session.
result = Solvethree(os.environ["SOLVETHREE_API_KEY"]).solve(request, timeout=180)
solution = result["solution"]
with requests.Session() as session:
    session.headers.update({"User-Agent": solution["userAgent"], "sec-ch-ua": solution["secChUa"]})
    proxies = {"http": proxy, "https": proxy}
    page = session.get(target, proxies=proxies, timeout=20, allow_redirects=False)
    page.raise_for_status()
    parser = FormParser(); parser.feed(page.text)
    if not parser.csrf: raise RuntimeError("The expected demo CSRF input was not found")
    response = session.post(target, proxies=proxies, timeout=20, allow_redirects=False,
        data={"csrf_token": parser.csrf, "g-recaptcha-response": solution["token"]})
    print("Application HTTP status:", response.status_code)
    # Use the actual form's submit URL, fields and session rules. Inspect its result.

L’appel solve du SDK crée la tâche et interroge son état jusqu’à ce qu’elle soit prête ou qu’une exception soit levée. L’exemple applique ensuite solution.userAgent et solution.secChUa à la session. Le GET remplit son conteneur de cookies ; le POST réutilise ce conteneur et envoie solution.token avec la valeur CSRF extraite du formulaire.

Modifiez l’action login, l’URL d’envoi et les champs du formulaire de la démonstration pour les adapter à votre application. csrf_token est le nom du champ de ce formulaire, pas une exigence de solvethree. Adaptez l’analyseur HTML si le vôtre utilise un autre nom ou une autre structure, et incluez tous les autres champs requis, comme les identifiants de connexion. Si l’URL d’envoi diffère de celle du formulaire, utilisez tout de même la même session.

Le statut HTTP affiché est un point de départ, pas la preuve que la connexion a réussi. Examinez la réponse de l’application et la requête sortante avant de payer pour une autre résolution. Une tâche prête signifie qu’une solution a été générée ; l’application décide toujours si elle accepte l’envoi.

Le champ CSRF est introuvable.

Vérifiez le statut et le corps de la réponse GET. Le suivi des redirections est désactivé : une réponse de redirection n’est donc pas le formulaire attendu.

Essayez ceci : Récupérez explicitement le bon formulaire via la même session, puis adaptez l’analyseur à son champ CSRF réel.

L’application signale une session manquante ou une valeur CSRF invalide.

Vérifiez si le GET a reçu des cookies, si le POST a envoyé les cookies applicables et si sa valeur CSRF provient de cette réponse de formulaire.

Essayez ceci : Gardez les deux requêtes dans la même requests.Session. Ne récupérez pas le formulaire avec un client pour l’envoyer avec un autre.

L’application rejette le CAPTCHA.

Examinez le champ de jeton sortant, l’action, le proxy, User-Agent et sec-ch-ua. Vérifiez que vous envoyez solution.token et non l’ID de la tâche ou un ancien jeton.

Essayez ceci : Utilisez le jeton actuel, le même proxy que pour la résolution et les en-têtes de navigateur renvoyés. Si le jeton a expiré ou a déjà été évalué, obtenez-en un nouveau peu avant l’envoi.

Le POST se termine, mais la connexion n’aboutit pas.

Examinez le corps de la réponse et toute destination de redirection, ainsi que l’URL d’envoi réelle et les champs de formulaire requis.

Essayez ceci : Adaptez les données du formulaire de la démonstration aux exigences de l’application. Un jeton CAPTCHA ne fournit ni identifiants ni autres champs d’application manquants.