Scarnox · Blog

Jak działa reCAPTCHA v2 i jak ją rozwiązać (wkrótce)

reCAPTCHA v2 to klasyczna captcha Google. Pokazuje pole wyboru z napisem „Nie jestem robotem” i, gdy nie jest pewna odwiedzającego, dodaje zadanie graficzne. Solver do niej musi wytworzyć poprawny token odpowiedzi, który strona może zweryfikować u Google. Obsługa reCAPTCHA v2 w Scarnox jest wkrótce. Ten przewodnik wyjaśnia, jak działa widget, jakie podejścia stosuje się dziś i czego oczekiwać od solvera opartego na tokenach.

Scarnox nie rozwiązuje jeszcze reCAPTCHA v2 na żywo. Jedynym dziś działającym typem zadania jest PopularCaptcha, proxyless. Jeśli twój projekt potrzebuje reCAPTCHA v2 już teraz, poniższe podejścia to realistyczne opcje.

Strona osadza element kontenera z atrybutem data-sitekey. Ten sitekey identyfikuje stronę u Google. Gdy widget się ładuje, uruchamia sprawdzenia w przeglądarce, patrząc na zachowanie odwiedzającego, ciasteczka i historię, i wysyła ocenę ryzyka do Google.

Jeśli ocena wskazuje niskie ryzyko, pole wyboru zaznacza się samo, a widget zapisuje token w ukrytym polu o nazwie g-recaptcha-response. Jeśli ocena wskazuje wyższe ryzyko, odwiedzający widzi zadanie graficzne, na przykład wybieranie kafelków z konkretnym obiektem. Zaliczenie wyzwania również zapisuje token.

Backend strony wysyła potem ten token do endpointu weryfikacji Google razem z kluczem tajnym strony. Google odpowiada sukcesem lub porażką. Ponieważ weryfikacja odbywa się po stronie serwera, formularz, który akceptuje token bez sprawdzenia go u Google, nie jest w ogóle chroniony przez reCAPTCHA.

Dlaczego jest oznaczany

Pole wyboru to decyzja o ryzyku, a nie zagadka. Typowe wyzwalacze to:

seria żądań z jednego adresu IP;
nowa sesja przeglądarki bez ciasteczek i historii;
środowisko przeglądarki, które wygląda na zautomatyzowane, na przykład domyślna konfiguracja headless;
wzorzec wejścia, który nie przypomina człowieka poruszającego myszą lub piszącego.

Zrozumienie tych wyzwalaczy ma większe znaczenie niż sam widget. Jeśli twój ruch nie uruchamia pola wyboru, nigdy nie zobaczysz zadania graficznego.

Ogólne podejścia, które działają dziś

Te podejścia są szeroko stosowane i są uczciwe. Zmniejszają częstotliwość pojawiania się wyzwań przy uprawnionej pracy.

Utrzymuj prawdziwe sesje. Używaj ponownie ciasteczek i spójnego profilu przeglądarki w ramach sesji, zamiast zaczynać od zera przy każdej stronie.
Dostosuj tempo żądań. Stałe, powolne tempo wygląda znacznie bardziej jak człowiek niż seria.
Używaj prawdziwej przeglądarki dla widgetu. Pełna przeglądarka z normalnymi ustawieniami rzadziej jest oznaczana niż odchudzona konfiguracja headless. Przewodnik o wykrywaniu headless browsera wymienia typowe sygnały.
Poproś o wyjątek lub klucz testowy. Jeśli jesteś właścicielem strony, używaj opublikowanych przez Google kluczy testowych na stagingu. Jeśli nie, poproś właściciela o dodanie do listy dozwolonych.
Zostaw człowieka w pętli. Przy zadaniach o małej skali człowiek może zaznaczyć pole i przekazać token dalej. Jest to wolne, ale niezawodne.

Te podejścia nie gwarantują, że wyzwanie nigdy się nie pojawi. Zmniejszają jego częstotliwość, a to utrzymuje stabilność uprawnionej pracy.

Czego się spodziewać po solverze opartym na tokenach

Solver reCAPTCHA v2 oparty na tokenach robi to, co PopularCaptcha robi dziś. Przyjmuje sitekey i adres URL strony, wytwarza poprawny token g-recaptcha-response i zwraca go do twojego kodu. Twój kod wpisuje potem token do formularza i wysyła go, zanim token wygaśnie.

Scarnox udokumentuje typ zadania i wszelkie dodatkowe pola w referencji API, gdy wsparcie reCAPTCHA v2 zostanie wydane. Do tego czasu nie buduj na założonym interfejsie. Kształt żądania będzie podobny do przykładu PopularCaptcha, ale sprawdź dokumentację, żeby poznać dokładne wartości.

Lista kontrolna dla zadania z reCAPTCHA v2

Planując zadanie, które dotyka formularza z reCAPTCHA v2, sprawdź te punkty:

Czy strona jest twoja? Jeśli tak, używaj kluczy testowych na stagingu i ogranicz testy na produkcji do minimum.
Czy zadanie jest uprawnione? Zbieranie danych publicznych i twoje własne przepływy pracy są uprawnione; nadużycia kont i spam już nie.
Czy tempo jest na tyle niskie, że pole wyboru pozostaje spokojne?
Czy masz plan na zadanie graficzne: człowiek albo solver, gdy będzie dostępny na żywo?
Czy sprawdzasz wynik weryfikacji po stronie serwera, a nie tylko obecność tokena?

Typowe błędy

Najczęstszym problemem integracji z reCAPTCHA v2 jest token, który strona odrzuca, mimo że wygląda poprawnie. Za większość takich przypadków odpowiadają trzy przyczyny. Pierwsza to niezgodność sitekey z adresem URL strony: token jest związany ze stroną, na której pokazano widget, więc sitekey pobrany z jednej strony i wysłany na inną zawiedzie. Druga to nieaktualny token. Tokeny są krótkotrwałe, więc skrypt, który rozwiązuje najpierw, a potem wykonuje długą sekwencję innych kroków, wyśle wygasłą wartość. Trzecia to brak weryfikacji po stronie serwera u ciebie. Jeśli twoje testy tylko potwierdzają, że token istnieje, nie zauważysz, że krok weryfikacji się nie udaje.

Druga grupa błędów wynika z przepływu pracy wokół widgetu. Częstym przykładem jest logowanie w jednej sesji, a wysyłanie formularza z innej, bo weryfikacja może zależeć od sesji, która załadowała widget. Wielokrotne ponawianie odrzuconego formularza pod rząd też sprawia, że sesja wygląda podejrzanie, co może zamienić jedno wyzwanie w serię kolejnych. Gdy coś się nie uda, zrób pauzę, sprawdź stan strony i spróbuj jeszcze raz ze świeżymi wartościami.

Scrapuj odpowiedzialnie

Jeśli formularz jest częścią zadania scrapingu, przed rozpoczęciem sprawdź robots.txt i regulamin strony. Utrzymuj niskie tempo i nie zbieraj danych osobowych, których nie potrzebujesz. Przewodnik o legalności web scrapingu omawia główne kwestie.