Акценти
Изборът на браузърен профил вече е параметър за всяка отделна заявка. Посочвате желания браузър и OS, а fingerprint-ът и съответните headers отразяват точно това. Single се научи да преминава още две проверки тази седмица (изчислителните защити на SiteGround и eBay), без да стартира Browser. Изгледът Activity в Dashboard вече записва това, което сте поискали, а не вътрешните процеси под него.
Какво ново
Избирайте браузърен профил за всяка заявка
Досега unblocker: true избираше един сигнатурен профил (текущия по подразбиране) и това беше всичко. Сега можете да посочите конкретен:
{ "url": "https://example.com", "unblocker": true, "profile": "firefox147" }
или задайте комбинация от браузър и операционна система:
{ "url": "https://example.com", "unblocker": true, "browser": "Chrome", "os": "Windows 10" }
API отхвърля непознати комбинации по име и извежда списък с наличните, така че печатна грешка не може тихо да изпрати сигнатура, която никога не сте заявявали.
Пълният каталог се намира на GET /api/profiles. Той е публичен (не се изисква ключ), защото представлява списък с възможности, а не тайна. Към момента на писане има 79 предварително зададени конфигурации за Chrome, Firefox, Edge, Safari и Tor под Windows, macOS, Android и iOS. Playground чете от същия списък, така че падащото меню винаги показва точно това, което вашият код може да поиска.
Защо е важно: ако целта ви профилира заявките по ОС или екипът ви прави A/B тестове кой стек преминава през дадена защита, вече можете да запазите тази променлива фиксирана, докато всичко останало се променя.
Single преминава изчислителните проверки на SiteGround и eBay
Две защити, които преди налагаха пренасочване през Browser, вече се преминават със Single. eBay използва свое собствено proof-of-work предизвикателство (Argon2 пъзел), а SiteGround изпълнява своя собствена проверка в голяма част от споделения хостинг уеб. И двете се решават без рендиране, което означава, че отговорът се връща под формата на единична HTTP заявка и се таксува съответно.
Сигналът за защита в отговорите също беше разширен. Отговорите от Browser вече съдържат defenses: { present, cleared }, за да виждате кой доставчик на защита стои пред страницата и дали сме преминали през него. Таксуването следва същото правило: всеки доставчик, през когото преминем, се отчита, независимо от бранда. Преди този период само една услуга за проверка се таксуваше като интерактивна страница. Вече към нея се добавят още три.
Изгледът Activity в Dashboard е преработен
Две колони в списъка Activity в Dashboard показваха некоректни данни. HTTP методът винаги показваше POST на всеки ред (всички наши endpoints са POST, така че колоната беше константа, която не носеше информация). А IP адресът на клиента при извиквания от Playground записваше откъде е направено извикването от самия Playground, а не потребителя, който натиска Run.
И двата проблема са отстранени. Колоната за метод вече показва глагола, изпратен в тялото на заявката. Клиентският IP адрес на редовете от Playground вече отчита IP адреса на браузъра на вписания потребител, пренесен в подписан Playground token, така че API клиент да не може да го фалшифицира.
Останалата част от изгледа също беше преработена. Таблицата се побира на екран на лаптоп без скриване на колони, колоната за продукт се слива с реда на заявката, а панелът с подробности получи табове, така че заявката, отговорът и обобщението на защитата да имат отделно превъртане.
Таксуване: 3D Secure при смяна на план
Ако вашият издател на карта изискваше 3DS потвърждение за смяна на план (а не само при първоначалния абонамент), тази стъпка не се задействаше и промяната се отменяше без съобщение. Вече се задейства. Ако сте опитали да смените план през последния месец и е изглеждало, че нищо не се случва, причината беше в това.
Под капака
Playground отказва да генерира хедър на отговор от данни на извлечен сайт (бъг от тип header injection, който хванахме рано). Endpoint за таксуване в Dashboard проверява дали извикващият притежава ресурса преди отговор, затваряйки вектор за IDOR.
Самият deploy pipeline получи сериозни корекции за цяла седмица, след като срив на 6-и запълни диска на deploy хоста по средата на билд. Всяка услуга отказва да се билдне без резерв на дисковото пространство, деплоите се сериализират, вместо да се надпреварват, gateway остава активен, когато даден backend прекъсва, а услугите действително спират при SIGTERM, вместо да увисват, докато не бъдат прекратени принудително тридесет секунди по-късно.
Дълго време решението „кой браузърен сигнатура“ взимахме ние вместо вас. Вече не е необходимо да бъде така.