Skip to main content
Denna artikel kommer att introducera en Recaptcha2 protokolligenkänning API integration instruktion, som gör att användare kan genomföra verifiering utan att behöva identifiera och klicka på Recaptcha2 verifieringsbilden, utan endast genom att skicka in Website Key för att uppnå automatisk avkodning i bakgrunden.

​
Ansökningsprocess

För att använda Recaptcha2 protokolligenkänning API, börja med att gå till Ace Data Cloud kontrollpanelen för att få din API Token, som du kan spara för framtida bruk. Om du inte har loggat in eller registrerat dig, kommer du automatiskt att omdirigeras till inloggningssidan som bjuder in dig att registrera dig och logga in, och efter att ha slutfört detta kommer du automatiskt att återvända till den aktuella sidan. En API Token räcker för att anropa alla plattformens tjänster, du behöver inte ansöka separat för varje tjänst. Första ansökan ger en gratis kvot, så att du kan prova gratis; när kvoten är otillräcklig kan du ladda på allmän balans i kontrollpanelen.
📘 Fullständig dokumentation: Recaptcha2 protokolligenkänning API →

​
Grundläggande användning

Först bör du förstå den grundläggande användningsmetoden, vilket är att ange URL:en för den webbplats som behöver hantera verifieringskoden, så får du det bearbetade resultatet. Först behöver du enkelt skicka ett website_url fält, vår exempelwebbplats är: https://www.google.com/recaptcha/api2/demo, vi behöver hämta website_key från website_url sidan, först öppna denna webbsida, tryck F12 för att gå till konsolen, och gör sedan en global sökning på Element-sidan efter recaptcha-demo, så får vi följande resultat:

Där data-sitekey motsvarar en sträng som är värdet av website_key, här är de specifika parameterresultaten:

Vi kan se att vi har ställt in Request Headers, inklusive:
  • accept: vilken format av svarresultat du vill ta emot, här anges som application/json, det vill säga JSON-format.
  • authorization: nyckeln för att anropa API, efter ansökan kan du direkt välja från rullgardinsmenyn.
Dessutom har vi ställt in Request Body, inklusive:
  • website_url: URL:en för den webbplats som behöver hantera verifieringskoden.
  • website_key: webbplatsens nyckelidentifierare i Recaptcha2.
  • proxy: valfritt, ta med egen proxy (Bring Your Own Proxy). När det är inställt kommer tjänsten att använda den proxy IP du tillhandahåller för att lösa verifieringskoden, för att kontrollera kvaliteten på utgående IP (till exempel för att undvika att offentliga proxy IP blockeras av målsidan och returnerar 410 Gone). Formatet är scheme://[user:pass@]host:port, där scheme stöder http/https/socks4/socks5, till exempel http://user:pass@1.2.3.4:8080. Om det inte fylls i används plattformens standardproxy.
När du har valt kan du se att motsvarande kod också har genererats till höger, som visas i bilden:

Klicka på “Try” knappen för att göra ett test, som visas i bilden ovan, här har vi fått följande resultat:
Resultatet innehåller flera fält, som beskrivs nedan:
  • token, resultatet av verifieringen efter att Recaptcha2-koden har behandlats.
  • started_at, finished_at: Tiden för när denna begäran började behandlas och när resultatet producerades, Unix-tidsstämpel (sekunder, flyttal).
  • elapsed: Den totala tiden för denna behandling (sekunder).
Vi kan se att vi har fått verifieringsresultatet för att behandla Recaptcha2-koden, och vi kan använda det för att POST:a eller simulera en inlämning till målsidan, engångsanvändning, giltighetstid 120 sekunder, rekommenderas att använda inom 60 sekunder. Nästa steg är att tillhandahålla en Python-version som skickar den behandlade token till målsidan för att passera Recaptcha2-koden. Först behöver vi ta reda på hur webbplatsen skickar POST-begäran, så att vi kan föra in den genererade token. Vi behöver först öppna F12-konsolen och sedan manuellt genomföra verifieringen. Slutligen kan vi se att webbplatsen skickade en POST-begäran, och vi behöver bara titta på konstruktionen av denna POST-begäran. Den specifika processen är som följer:
  • Genomför först verifieringen manuellt, som visas i bilden nedan:

  • Klicka sedan på skicka, och observera förändringarna i nätverkskonsolen, som visas i bilden nedan:

  • Analysera konstruktionen av POST-förfrågan i denna inlämning, och du kan högerklicka på förfrågan för att kopiera CURL-koden, som visas i bilden nedan:

Från bilden ovan kan vi se att URL:en för denna POST-förfrågan är: https://www.google.com/recaptcha/api2/demo, vi behöver bara skicka parametern g-recaptcha-response, och sedan behöver vi bara överföra den bearbetade token i datan nedan, CURL-koden för att anropa token för verifiering ser ut som följer:
Koden för att anropa token-verifiering i Python ser ut som följer:
Sedan kör vi koden och observerar att konsolen visar ett sådant resultat:

Till slut har vi genomfört verifieringen av Recaptcha2-koden. Om du vill generera motsvarande integrationskod kan du direkt kopiera den som genereras, till exempel CURL-koden ser ut som följer:
Python-integrationskoden ser ut som följer:

​
Asynkront läge (async)

Som standard är API:et synkront och blockerande: en förfrågan kommer att vänta tills token-behandlingen är klar innan den returneras. Om du gör en multipel kodlösning (multi-solver rotation) och vill “omedelbart få task_id efter att ha skickat in uppgiften, först schemalägga andra kodlösare och sedan återkomma för att läsa resultatet”, kan du skicka in async: true i begäran. När du skickar in async: true kommer gränssnittet omedelbart att returnera ett task_id utan att blockera väntan:
Om du vill se framstegen aktivt kan du använda detta task_id för att fråga POST /captcha/tasks (rekommenderas var 3-5 sekund). Detta gränssnitt kommer inte att utlösa eller påskynda uppgiftsbehandlingen; även om du inte frågar, tappar internetanslutningen eller stänger klienten, kommer servern fortfarande att fortsätta behandlingen:
Under behandling kommer det att returnera status: processing:
När behandlingen är klar kommer det att returnera status: ready och token:
Avgiftsbeskrivning: I asynkront läge debiteras inte skapandet av uppgifter och läsning av “under behandling”-status; klienten debiteras en gång när den första framgångsrika läsningen av resultatet görs (samma som nuvarande beteende och priser för synkront läge). Servern kommer att driva uppgiften själv, men kommer inte att debitera i förväg bara för att bakgrunden slutförs först. Om uppgiften inte lyckas inom 120 sekunder kommer den att avslutas med HTTP 504 timeout, utan debitering. /captcha/tasks ansvarar inte för att driva uppgiften.

​
Felhantering

När du anropar API:et, om du stöter på fel, kommer API:et att returnera motsvarande felkod och information. Till exempel:
  • 400 token_mismatched: Bad request, möjligtvis på grund av saknade eller ogiltiga parametrar.
  • 400 api_not_implemented: Bad request, möjligtvis på grund av saknade eller ogiltiga parametrar.
  • 401 invalid_token: Unauthorized, ogiltig eller saknad auktoriseringstoken.
  • 429 too_many_requests: För många förfrågningar, du har överskridit hastighetsgränsen.
  • 500 api_error: Intern serverfel, något gick fel på servern.

​
Exempel på felrespons

​
Slutsats

Genom detta dokument har du fått en förståelse för hur du använder Recaptcha2-protokollet för att identifiera API så att användare inte behöver identifiera och klicka på Recaptcha2-verifieringsbilden, utan bara behöver skicka in Website Key för att möjliggöra automatisk avkodning i bakgrunden och slutföra verifieringen. Vi hoppas att detta dokument kan hjälpa dig att bättre integrera och använda detta API. Om du har några frågor, tveka inte att kontakta vårt tekniska supportteam.