Najważniejsze informacje
Wybór profilu przeglądarki jest teraz parametrem konfigurowanym per-request. Wskaż żądaną przeglądarkę oraz system operacyjny, a fingerprint i nagłówki będą ze sobą spójne. Single potrafi od tego tygodnia przejść dwa kolejne testy (obliczeniowe weryfikacje SiteGround oraz eBay) bez uruchamiania instancji Browser. Dodatkowo widok Activity w Dashboardzie rejestruje teraz parametry Twojego żądania, a nie wewnętrzne operacje wykonane pod spodem.
Co nowego
Wybór profilu przeglądarki per-request
Do tej pory unblocker: true wybierał jedną sygnaturę (nasz aktualny profil domyślny) i na tym koniec. Teraz możesz wskazać konkretną:
{ "url": "https://example.com", "unblocker": true, "profile": "firefox147" }
lub zażądaj pary przeglądarki i systemu operacyjnego:
{ "url": "https://example.com", "unblocker": true, "browser": "Chrome", "os": "Windows 10" }
API odrzuca nieznane kombinacje wedlug nazwy i wyswietla liste tego, co JEST dostepne, wiec literowka nie wysle po cichu sygnatury, o ktora wcale nie prosiles.
Pelny katalog znajduje sie pod adresem GET /api/profiles. Jest publiczny (klucz nie jest wymagany), poniewaz to lista mozliwosci, a nie sekret. W chwili pisania tego tekstu dostepnych jest 79 presetow obejmujacych Chrome, Firefox, Edge, Safari i Tor, na systemach Windows, macOS, Android oraz iOS. Playground korzysta z tej samej listy, wiec rozwijane menu zawsze pokazuje dokladnie to, czego moze zazadac Twoj kod.
Dlaczego to ma znaczenie: jesli Twoj cel profiluje requesty wedlug systemu operacyjnego lub Twoj zespol prowadzi testy A/B sprawdzajace, ktory stos radzi sobie z dana blokada, mozesz teraz utrzymac te zmienna na stalym poziomie, podczas gdy wszystko inne sie zmienia.
Single radzi sobie z wyzwaniami obliczeniowymi SiteGround i eBay
Dwa zabezpieczenia, ktore wczesniej wymuszaly przejscie przez Browser, sa teraz obslugiwane w Single. eBay stosuje wlasne wyzwanie proof-of-work (zagadka Argon2), a SiteGround uruchamia wlasna weryfikacje w duzej czesci sieci shared hostingu. Oba rozwiazuja sie bez renderowania, co oznacza, ze response wraca w formie pojedynczego requestu HTTP i jest odpowiednio wyceniany.
Rozszerzylismy takze sygnature zabezpieczen w odpowiedziach. Odpowiedzi Browser zawieraja teraz defenses: { present, cleared }, dzieki czemu mozesz zobaczyc, jaki dostawca zabezpieczen znajdowal sie przed strona i czy udalo sie przez niego przejsc. Rozliczenia dzialaja wedlug tej samej zasady: kazdy ominiety dostawca zostaje przypisany, niezaleznie od marki. Przed tym wydaniem tylko jedna usluga weryfikacji byla rozliczana jako strona interaktywna. Teraz dolaczyly do niej trzy kolejne.
Przebudowany widok Activity w Dashboardzie
Dwie kolumny na liscie Activity w Dashboardzie pokazywaly bledne informacje. Metoda HTTP zawsze wskazywala POST w kazdym wierszu (wszystkie nasze endpointy to POST, wiec kolumna byla stala wartoscia, ktora nic nie mowila). Z kolei IP klienta przy wywolaniach z Playground rejestrowalo miejsce, skad Playground wykonywal polaczenie, a nie osobe klikajaca Run.
Oba problemy zostaly naprawione. Kolumna metody pokazuje teraz czasownik przekazany w tresci requestu. IP klienta w wierszach Playground wskazuje teraz IP przegladarki zalogowanego uzytkownika, przekazywane w podpisanym tokenie Playground, wiec klient API nie moze go sfalszowac.
Przy okazji przebudowalismy reszte widoku. Tabela miesci sie na ekranie laptopa bez ukrywania kolumn, kolumna produktu zostala polaczona z linia requestu, a panel szczegolow zyskal zakladki, dzieki czemu request, response i podsumowanie zabezpieczen maja wlasne przewijanie.
Rozliczenia: 3D Secure przy zmianie planu
Jesli wystawca Twojej karty wymagal potwierdzenia 3DS przy zmianie planu (a nie tylko przy poczatkowej subskrypcji), ten krok sie nie uruchamial, a zmiana byla po cichu wycofywana. Teraz dziala prawidlowo. Jesli w ciagu ostatniego miesiaca probowales zmienic plan i wygladalo na to, ze nic sie nie stalo, to wlasnie dlatego.
Pod maska
Playground odrzuca probe budowania naglowka response z danych pobranej strony (klasa bledu header-injection, ktora wylapalismy na wczesnym etapie). Endpoint rozliczeniowy w Dashboardzie weryfikuje, czy wywolujacy jest wlascicielem zasobu przed zwroceniem odpowiedzi, co zamyka sciezke podatnosci IDOR.
Sam pipeline wdrożeniowy przeszedł serię poprawek po awarii z 6. dnia miesiąca, kiedy to dysk hosta wdrożeniowego zapełnił się w trakcie budowania. Każda usługa odmawia teraz budowy bez odpowiedniego zapasu miejsca na dysku, wdrożenia są serializowane zamiast rywalizować ze sobą, gateway pozostaje aktywny przy niestabilności backendu, a usługi prawidłowo kończą działanie po odebraniu sygnału SIGTERM, zamiast wisieć do momentu ubicia po trzydziestu sekundach.
Przez długi czas to my decydowaliśmy za Ciebie o wyborze sygnatury przeglądarki. Już tak nie musi być.