Как стать автором
Обновить

Комментарии 5

Интересно, как вы разруливаете, когда непустой proxy_n (ибо, например, надо с авторизационной кукой парсить раздел сайта для залогиненных), но сервер отдал, например, 403, или отправил ссылку на челлендж.

Логично, что надо новую сессию создавать с 0, чтобы не запачкать новый ip старой токсичной кукой. Ибо, если сервис начнёт втупую ротировать прокси, то владелец ресурса будет очень рад, - он, сгрупировав по куке, пометит все ип вашего пула, и game over.

Кажется, что тут уже логикой mitm не обойтись

PS: ещё интересная мысль появилась после прочтения. Учитывая, что авторотаторы прокси внутри умного прокси вещь очень распространенная на рынке. Правда, как правило, готовые saas провайдеры просто socks5 интерфейс дают, а под капотом уже логика ротации по не 200 ответу.

Выходит, что при защите от парсинга важно искать в логах доступа запрос, который пришёл в течении пары секунд после заблокированного запроса, но имеет те же хедеры, юзерагент, путь и другой ип. С высокой вероятностью этот ип принадлежит прокси сервису.

хоть и не ТС, но отвечу... юзерагенты тоже можно ротировать и подставлять внутри mitm прокси из набранного пула.

Проблему авторизации с одного ip... да и вообще в любых ситуациях, когда надо использовать чейн запросов с одного адреса... никто ж не запрещает клиенту передавать через хидеры в mitm прокси управляющие заголовки с просьбой использовать конкретный апстрим, который ранее выдался рандомно при первом запросе. Не спорю, тут немного теряется прозрачность, и клиента надо обучать этой логике держания в памяти ip апстрима, через который он начал общаться, но что поделать... это ведь не самая частая ситуация.

О, видите, как сразу сложность наростает)

Если mitm сам решает за юзерагент, то, банально, даже понять мобильный/десктопный юа ставить, уже управляющий хедер нужен.

А, касательно рандомного выбора апстрима при чейне - наверное, все же, тут уже надо все делать прозрачно для клиента. Ибо есть хороший вариант испачкать много ip на первом же запросе, который должен по логину и паролю авторизационную куку получить, если логин уже заблокирован за парсинг

Хорошая работа. В опенсорс планируете выложить?

Пока что не планируем. Возможно в будущем

Зарегистрируйтесь на Хабре, чтобы оставить комментарий