Акценти
Преди организацията беше просто ред, който можеше да побере само един човек. Сега това е страница, която управлявате: поканете колега, задайте му роля, позволете му да създава ключове, за които фирмата плаща. Proxy Finder също спря да връща съобщение за изчерпани опити и започна да посочва конкретната преграда, на която се е натъкнал, а 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. Към това е включено и ясно обобщаващо изречение.
Но именно последната бройка е тази, която има най-голямо значение. Правило за съдържание, което не открива съвпадение, изглежда точно като блокиране от всяка гледна точка, която измервахме преди, и нито един повторен опит няма да помогне. (Повече за това как правилата за валидация определят успеха.)
Другата половина от решението е профилът. Proxy Finder сменяше изходните точки, но никога клиентския подпис (client signature), така че сайт, отхвърлящ определен браузърен профил, го отхвърляше на всеки изходен адрес от пула. Сега отказът води до промяна на профила при повторния опит, който така или иначе щеше да се изпълни, така че заявките и кредитите за задача остават същите. Задайте profile ръчно и нищо няма да се промени. Имайте предвид, че при най-трудните цели изходната точка, на която попадате, все още е от по-голямо значение от профила, който изпращате.
Browser спира да си противоречи
Изискването на User-Agent от Browser преди беше по-лошо, отколкото да не се изисква изобщо. Три слоя имаха собствена представа за това кой изпраща заявката, така че една заявка можеше едновременно да твърди, че е Windows, Mac и версия, която инфраструктурата изобщо не използва. Вече има само една стойност, определена еднократно и предавана навсякъде: при стартирането, в страницата и в работните процеси, които страницата стартира.
Client hints се извеждат от този низ, така че sec-ch-ua, платформата и navigator.platform съвпадат с него. Върнатият response отчита низа, който действително сме изпратили, което е важно, тъй като clearance бисквитките са обвързани едновременно с изходната точка и с User-Agent. Въпросът за renderer вече връща еднакъв отговор както в документа, така и в работния процес, което е още един от слабите сигнали, които се натрупват.
Заедно с това бяха въведени още три подобрения:
- Часовникът следва изходната точка. Browser работи в часовата зона на държавата, в която се намира изходната точка, така че страница, рендираща локално време, показва това, което би видял посетител оттам. Когато държавата не е известна, часовникът остава непроменен.
- WebRTC остава по същия път като всичко останало. Proxy настройката покрива това, което браузърът изпраща през TCP. WebRTC не минава по този път, така че страница, която изисква ICE кандидати от него, получава отделен отговор. Browser изключва това винаги, когато заявката съдържа зададена изходна точка.
- URL адресите с котва изразходват нормално време. URL, завършващ на
#reviews, преди водеше до изтичане на времето всеки път. Вече работи с нормална скорост.
По-евтини маршрути и табло за управление с точно отчитане
Imperva инжектира своя скрипт в изправни страници, а не само в страниците за отказ, и Auto не можеше да ги разграничи, поради което изправните страници се прехвърляха към браузър без нужда. При сайт за коли под наем това струваше 75 кредита и 27.5 секунди в шест опита. Сега е един опит, 10 кредита и около шест секунди и половина. Някои сайтове връщат сесия в рамките на отказа, с който отговарят на заявка без сесия, и четирите енджина вече я изпращат обратно директно, преди да ескалират към браузър.
Картата за кредити в Общ преглед показваше всичко изразходвано и го обозначаваше като фактурирано. При модел pay-for-success тези стойности се различават, а разликата е реални пари, така че на картата вече присъстват и двете: фактурираната сума като основно число и изразходваната под нея, по продукт и общо. Картата за Заявки е разделена по същия начин. Периодът и нивото на детайлност също са отделни контроли, от 30 минути до една година плюс персонализиран диапазон, заменяйки бутона, който показваше "1D" и отваряше тридесет дни.
В Playground бутонът за пренасяне вече предлага профила от последния response, така че заявка, изпратена с профил, който не сте въвели ръчно, повтаря версията, която е сработила. Всеки параметър е описан в API reference.
Под капака
Proxy Finder пази повече история за всеки хост: 32 изхода вместо дузина. При реален A/B тест се представи на същото ниво при лесни цели и по-добре при трудни, където медианното време за страница спадна от 5.5s на 3.8s, докато латентността в цялата мрежа остана непроменена. Една от целите показа обратен резултат и все още не знаем защо, затова получава отделно измерване.
Задача, която ще се провали, ще се провали и в двата случая. Разликата е дали ще затворите тикета за минута, или ще прекарате следобеда в измерване на грешното нещо.