Web API ma jawne limity i kod 429 z informacją, kiedy ponowić. Panel i strony sklepu takich limitów nie podają, a w obu opisanych przypadkach seria zapytań, która wyglądała na skanowanie albo masowe pobieranie, skończyła się blokadą adresu IP na kilka godzin. Skrypty, które muszą korzystać z panelu albo stron, warto pisać tak, żeby obchodziły się z nimi jak człowiek.
| Sklep A | Sklep B | |
|---|---|---|
| Wyzwalacz | 17 zgadywanych adresów w panelu w krótkim czasie, większość z odpowiedzią 404 | około 270 pobrań stron listingu jedno po drugim |
| Zablokowane | panel i sklep z tego adresu IP | panel i sklep z tego adresu IP |
| Web API | działało (odczyt z kodem 200) | według notatek przestało działać |
| Czas | około 4 godzin | dwie blokady w jednej sesji, druga około 4 godzin |
Objaw: „Zostałeś zablokowany” tylko z jednego adresu
Tę samą krótką odpowiedź dostaje przeglądarka i skrypt. W jednym ze sklepów odpowiedź miała 84 bajty, w drugim przychodziła z kodem 200, więc skrypt, który patrzy tylko na kod odpowiedzi, uzna ją za poprawną stronę. Zmiana nagłówka User-Agent nic nie daje, bo blokada dotyczy adresu IP, a nie tego, jak przedstawia się klient.
Z innego adresu sklep może działać normalnie. W sklepie A sprawdzenie z innej sieci zaplanowaliśmy, ale go nie wykonaliśmy; notatki mówią tylko, że sklep działał dla klientów. Tego, czy blokada obejmuje innych odwiedzających, nie da się więc stwierdzić z zablokowanej maszyny.
Co wywołało blokadę w dwóch sklepach
W sklepie A skrypt szukał w panelu miejsca na własny kod w nagłówku strony i w krótkim czasie odpytał 17 adresów panelu zgadywanych z nazw. Większość zwróciła 404. Dla zabezpieczenia to dokładnie wzorzec skanowania w poszukiwaniu luk, więc adres został zablokowany.
W sklepie B przyczyną była liczba pobrań: około 270 stron listingu, po kilkaset kilobajtów każda, jedna po drugiej. Zapisy przez Web API w tym samym sklepie nigdy blokady nie wywołały.
Shoper nie publikuje progów tego zabezpieczenia, a infolinia nie potrafiła ich podać ani sprawdzić stanu blokady. Z dwóch przypadków wynika tylko tyle, że blokadę wywołuje zarówno wzorzec (zgadywanie adresów z wieloma błędami 404), jak i sama liczba szybkich pobrań stron.
Panel i strony a Web API: zaobserwowany zasięg blokad
Web API ma jawne limity. Odpowiedzi niosą nagłówki z limitem i bieżącym zużyciem, a po przekroczeniu przychodzi kod 429 z informacją, po ilu sekundach ponowić. Opisuje to tabela na stronie o integracjach przez Shoper API. Odpowiedzi panelu i stron sklepu, które widzieliśmy, nie miały nagłówków limitu ani informacji o ponowieniu, więc o przekroczeniu dowiadywaliśmy się dopiero z blokady.
Zasięg blokad był różny: w sklepie A blokada objęła panel i strony, a API z tego samego adresu działało; w sklepie B według notatek zatrzymało się też API. Dwa przypadki nie wystarczą, żeby opisać, jak zabezpieczenie Shopera jest zbudowane, więc nie warto zakładać, że API zawsze zostaje dostępne.
Co zrobić, gdy blokada już jest
- zatrzymaj wszystkie zapytania do panelu i stron sklepu z tego adresu, łącznie ze sprawdzaniem, czy blokada już minęła; w sklepie A przerwaliśmy je od razu jako środek ostrożności, bez dowodu, że kolejne zapytania przedłużają blokadę
- sprawdź sklep z innej sieci, żeby wiedzieć, czy problem dotyczy klientów
- jeśli Web API działa, pilne prace rób przez API
- w obu sklepach blokada trwała około czterech godzin; w jednym z przypadków pracę można było wznowić po zmianie sieci
Jak pracować, żeby blokady nie dostać
- w panelu nie odpytuj adresów, których istnienia nie znasz: przechodź po linkach z samego panelu, a adresy potrzebne skryptowi bierz z ruchu sieciowego przeglądarki
- strony sklepu pobieraj wolno: w sklepie B przyjęliśmy najwyżej około 60 pobrań na sesję z przerwą 2–3 s
- dane do analizy pobieraj raz do pliku i pracuj na pliku, zamiast odpytywać sklep ponownie
- dane katalogu bierz z Web API, a nie ze stron: w sklepie A po wcześniejszej blokadzie API odpytujemy w tempie 3 zapytań na sekundę, mimo że nagłówek limitu pozwala na więcej
- w skrypcie traktuj odpowiedź z napisem „Zostałeś zablokowany” jako błąd i zatrzymuj pracę, nawet jeśli kod odpowiedzi to 200
Kiedy poradzisz sobie sam, a kiedy z kimś
Jednorazowe pobranie danych przez Web API z przestrzeganiem limitów i krótka praca w panelu przez przeglądarkę. Przy blokadzie: przerwa, sprawdzenie z innej sieci i praca przez API, jeśli działa.
Regularne automaty, które pobierają strony sklepu albo działają w panelu, masowe analizy katalogu i procesy, które muszą działać w nocy bez nadzoru.
Gdy zlecasz nam automatyzację w Shoperze, dostajesz proces oparty na Web API z kontrolą limitów, pobieranie stron tylko tam, gdzie API nie wystarcza, w ograniczonym tempie, oraz zatrzymanie pracy przy pierwszym sygnale blokady. To zmniejsza ryzyko blokady, ale go nie wyklucza. Więcej o pracy przez Shoper API i w przeglądzie najczęstszych błędów Shoper API.