Главное
Раньше организация была просто строкой, где мог находиться только один человек. Теперь это полноценная страница управления: приглашайте коллег, назначайте роли, давайте им создавать ключи за счет компании. Proxy Finder перестал выдавать общую ошибку об исчерпании попыток и начал точно указывать причину блокировки. А Browser получил доработки, чтобы отдавать целевой странице согласованные данные.
Что нового
Полноценное управление организациями
Раньше для добавления коллеги приходилось писать нам на почту, поэтому команды нередко оформляли две независимые подписки.
Теперь у организации есть отдельная страница в Dashboard с тремя ролями. Владелец привязан к подписке, с которой списываются средства за ключи. Владелец всегда один, и владение передается вручную. Администраторы управляют использованием, биллингом и участниками. Участники работают с сервисом. Приглашения отправляются по email и работают даже для тех, у кого еще нет аккаунта.
Любой участник организации может создавать ключи внутри нее и переносить туда личные ключи, поэтому разработчикам больше не нужно оплачивать рабочие задачи из своего кармана. Расходы по ключам организации списываются с тарифа владельца, и каждое подтверждение явно показывает, чей тариф используется. Переименовать ключ может любой участник. Перегенерация, отключение и удаление доступны только владельцам и администраторам, так как эти действия мгновенно блокируют работу всех коллег, использующих этот ключ.
Единый фильтр Owner действует в разделах Overview, Detailed Metrics, Recent Activity и в списке ключей. Разделы Usage & Limits и Billing остаются персональными, так как участникам не нужен доступ к квотам владельца.
Точная диагностика в Proxy Finder
Ошибка "Download maxTry limit reached" выглядела одинаково, если все выходные узлы были заблокированы, если они были недоступны или если мы успешно получили страницу, но ваше собственное правило ее отклонило. Эти три ситуации требуют совершенно разных решений.
Теперь при сбое задачи возвращается attemptReport: сколько узлов не ответили, сколько было отклонено известными системами защиты (с указанием конкретных систем), сколько отклонило ваше validate.status и сколько вернули HTTP 200 без признаков защиты, но не прошли ваше validate.data. К этим данным прилагается понятное текстовое резюме.
Последняя метрика особенно важна. Ошибка в правиле проверки контента по прежним метрикам выглядела в точности как блокировка, и повторные попытки здесь бессмысленны. (Подробнее о том, как правила validate определяют успешность.)
Вторая часть обновления касается профилей. Раньше Proxy Finder ротировал только выходные узлы, сохраняя неизменным сигнатуру клиента. Если сайт отклонял определенный профиль браузера, он отклонял его на всех узлах пула. Теперь при отказе профиль меняется автоматически в рамках уже запланированной повторной попытки, поэтому число запросов и списание кредитов на задачу остаются прежними. Если зафиксировать profile вручную, поведение не изменится. При этом на самых сложных целях выбор выходного узла по прежнему важнее отправляемого профиля.
Browser работает согласованно
Запрашивать у Browser значение User-Agent раньше было хуже, чем не запрашивать вовсе. Три слоя по-своему определяли источник запроса, поэтому один запрос мог одновременно заявлять Windows, Mac и версию, которой вообще не было на серверах. Теперь используется одно значение: оно определяется один раз и передается везде, включая запуск, страницу и воркеры, которые эта страница создает.
Client hints формируются на основе этой строки, поэтому sec-ch-ua, платформа и navigator.platform согласованы с ней. В ответе возвращается строка, которую мы действительно отправили. Это важно, так как clearance cookie привязаны одновременно к точке выхода и к User-Agent. Ответ рендерера теперь также совпадает в документе и в воркере, закрывая еще один из слабых сигналов, которые складываются в общую картину.
Вместе с этим вышли еще три улучшения:
- Часы синхронизируются с точкой выхода. Browser работает в часовом поясе страны, где находится выходной узел, поэтому страница с локальным временем отображает именно то, что увидел бы пользователь оттуда. Если страна не определена, время не меняется.
- WebRTC идет по тому же маршруту, что и весь остальной трафик. Настройки proxy покрывают то, что браузер отправляет по TCP. WebRTC не входит в этот маршрут, поэтому при запросе ICE candidates страница получает отдельный ответ. Browser отключает это поведение, когда запрос содержит точку выхода.
- URL с анкорами обрабатываются без задержек. URL, заканчивающийся на
#reviews, раньше каждый раз приводил к таймауту. Теперь скорость вернулась к норме.
Более дешевые маршруты и точный подсчет в Dashboard
Imperva внедряет свой скрипт не только на страницы с блокировкой, но и на обычные страницы. Режим Auto не мог их различить, поэтому нормальные страницы зря передавались в браузер. На сайте аренды автомобилей это стоило 75 кредитов и занимало 27.5 секунд за шесть попыток. Теперь это одна попытка, 10 кредитов и около шести с половиной секунд. Некоторые сайты передают сессию прямо в ответе с отказом на запрос без сессии, и теперь все четыре движка отправляют ее обратно перед эскалацией.
Карточка кредитов в Overview показывала все списания и помечала их как оплаченные. В модели оплаты за результат эти показатели различаются, и разница ощутима в деньгах. Теперь на карточке выводятся оба значения: оплаченные в качестве основного числа, фактически потраченные под ним, по каждому продукту и суммарно. Карточка Requests разделена аналогично. Период и детализация теперь настраиваются отдельно, от 30 минут до года плюс произвольный интервал, заменяя старый переключатель с надписью "1D", который открывал тридцать дней.
В Playground кнопка переноса теперь предлагает профиль из последнего ответа, поэтому запрос, отправленный с профилем, который вы не вводили вручную, повторяет успешно сработавшую версию. Все параметры описаны в API reference.
Under the Hood
Proxy Finder сохраняет больше истории для каждого хоста: 32 выходных узла вместо дюжины. В ходе живого A/B тестирования показатели совпали на простых целях и улучшились на сложных, где медианное время до страницы снизилось с 5.5s до 3.8s, в то время как общая задержка по всему пулу не изменилась. Один целевой ресурс показал обратный результат, и мы пока не выяснили причину, поэтому для него выделены отдельные замеры.
Задача, которая обречена на сбой, завершится ошибкой в любом случае. Разница лишь в том, закроете ли вы тикет за минуту или потратите весь день на поиск проблемы не там, где нужно.