Highlights
Преди една организация беше просто ред, който можеше да съдържа само един човек. Сега това е страница, която управлявате: поканете колега, задайте му роля, позволете му да създава ключове за сметка на компанията. Proxy Finder също спря да отговаря с "out of tries" и започна да посочва конкретната пречка, а Browser прекара седмицата в гарантиране, че показва последователни данни при всяко зареждане на страница.
Какво ново
Организации, които реално можете да управлявате
Добавянето на колега преди изискваше имейл до нас, така че екипите купуваха два отделни абонамента.
Сега вашата организация има собствена страница в Dashboard с три възможни роли. Собственикът (owner) държи абонамента, към който се таксуват нейните ключове, така че има точно един такъв, а собствеността се променя чрез прехвърляне. Администраторите (admins) управляват потреблението, фактурирането и членовете. Членовете (members) просто използват продукта. Поканите се изпращат по имейл и работят дори за хора, които все още нямат регистрация.
Всеки в организацията може да създава нейни ключове и да мести личен ключ в нея, така че разработчикът да не плаща лично за фирмена работа. Потреблението на ключ на организацията се таксува към плана на собственика, като всяко потвърждение показва чий план плаща. Всеки член може да преименува ключ. Прегенерирането, деактивирането и изтриването остават само за собственици и администратори, тъй като те спират работата на всеки колега, използващ ключа, в момента на изпълнение.
Филтърът Owner работи в Overview, Detailed Metrics, Recent Activity и списъка с ключове. Usage & Limits и Billing остават лични, тъй като членовете нямат работа в квотите на собственика.
Proxy Finder спира да гадае
Съобщението "Download maxTry limit reached" изглеждаше еднакво, независимо дали всеки изход е блокиран, всеки изход е неактивен, или сме изтеглили истинската страница, но вашето собствено правило я е отхвърлило. Тези три случая изискват напълно различни решения.
Неуспешната задача вече съдържа attemptReport: колко изхода не са отговорили, колко са били блокирани от разпозната защита и кои доставчици са го направили, колко са отхвърлени от вашето validate.status и колко са върнали HTTP 200 без видима защита, но са се провалили единствено на вашето validate.data. Към това е добавено и ясно обобщаващо изречение.
Именно последната бройка е най-важната. Правило за съдържание, което не открива съвпадение, изглеждаше досущ като блокиране от всяка гледна точка, която измервахме преди, и нито един retry не може да го оправи. (Повече за това как правилата за валидация определят успеха.)
Другата част е профилът. Proxy Finder ротираше изходите, но никога клиентския подпис, така че сайт, който отхвърля даден браузърен профил, го отхвърляше на всеки изход в пула. Сега отказът сменя профила при следващия retry, който така или иначе щеше да се изпълни, така че броят заявки и кредити за задача не се променя. Задайте profile ръчно и нищо няма да се промени. При най-трудните цели изходният адрес все още е по-важен от изпратения профил.
Browser спира да си противоречи
Изискването на User-Agent от Browser преди беше по-лошо от това изобщо да не се изисква. Три различни слоя имаха собствена представа за това кой прави заявката, така че една заявка можеше едновременно да твърди, че е Windows, Mac и версия, която клъстерът изобщо не използва. Сега има една стойност, определена еднократно, предавана навсякъде: при стартирането, в страницата и в уъркърите, които страницата създава.
Client hints се извличат от този низ, така че sec-ch-ua, платформата и navigator.platform съвпадат с него. Response връща низа, който реално сме изпратили, което е важно, защото clearance cookies са обвързани едновременно с exit точката и с User-Agent. Въпросът за renderer също връща един и същ отговор в документа и в уъркъра, още един от слабите сигнали, които се натрупват.
Заедно с това бяха добавени още три подобрения:
- Часовникът следва exit локацията. Browser работи в часовата зона на държавата, в която се намира вашият exit, така че страница, визуализираща локално време, показва това, което би видял посетител оттам. Когато държавата е неизвестна, часовникът не се променя.
- WebRTC остава по същия маршрут като всичко останало. Proxy настройката покрива това, което браузърът изпраща през TCP. WebRTC не минава по този маршрут, така че страница, която изисква от него ICE candidates, получава отделен отговор. Browser изключва това винаги, когато заявката носи exit.
- URL адресите с котва струват толкова, колкото трябва. URL, завършващ на
#reviews, преди водеше до изтичане на времето за изчакване всеки път. Вече работи с нормална скорост.
По-евтини маршрути и табло за управление с точно отчитане
Imperva инжектира своя скрипт в изправни страници, а не само в страниците си за блокиране, като Auto не можеше да ги различи, поради което изправни страници се ескалираха към браузър без причина. В сайт за коли под наем това отнемаше 75 кредита и 27.5 секунди в шест опита; сега е един опит, 10 кредита, около шест секунди и половина. Някои сайтове връщат сесия вътре в отказа, с който отговарят на заявка без сесия, и четирите енджина вече я изпращат обратно веднага, преди да ескалират.
Картата за кредити в Overview показваше всичко изразходвано и го обозначаваше като фактурирано. При модела pay-for-success тези стойности се различават, а разликата представлява реални пари, така че и двете са на картата: фактурираното като основно число, изразходваното под него, по продукти и общо. Картата за Requests се разделя по същия начин. Периодът и детайлността също са отделни контроли, от 30 минути до една година плюс персонализиран диапазон, като се премахва бутонът, който показваше "1D" и отваряше тридесет дни.
Във Playground бутонът за пренасяне вече предлага профила от последния response, така че заявка, изпратена с профил, който не сте въвели ръчно, повтаря версията, която е сработила. Всеки параметър е описан в API reference.
Под капака
Proxy Finder пази повече история за всеки хост: 32 изхода вместо дузина. При A/B тест на живо се представи еднакво при лесни таргети и по-добре при трудни, където медианното време за страница спадна от 5.5s на 3.8s, докато латентността в целия fleet остана непроменена. Един таргет показа обратен резултат и все още не знаем защо, затова получава отделно измерване.
Задача, която ще се счупи, ще се счупи така или иначе. Разликата е дали затваряте тикета за минута, или прекарвате следобеда в измерване на грешното нещо.