Comments 9
Спасибо!
Можно было не патчить fetch, а написать просто свой агент на его основе или на основе каких-нибудь axios или superagent.
И раз уж запрос шлётся через свой агент (в вашем случае, кстати, тоже), то не нужно вслепую делать первый запрос. Можно же хранить время получения токена, и если время жизни токена истекло, то сперва запросить новый токен, а потом уже идти за данными.
Если я правильно понял идею - то она примерно такая же как в примере с кастомным fetch с названием customFetch_USE_IT_OR_WILL_BE_FIRED. Основная проблема что мы не можем заставить nextjs использовать наш собственный агент, а nextjs при этом также получает 403 ошибки уже при навигации между страницами
Т.е. сначала подключили сторонний сервис, а потом с ним боролись? Не проще было fingerprint самим использовать?
Вполне возможно что в каких-то моментах было проще в плане настройки под себя, но это получается лишняя точка отказа на нашей стороне и также необходимо тратить ресурсы на поддержку. Плюс собрать у себя хороший детектор ботов кажется довольно непростой задачей, а учитывая что боты они могут постоянно совершенствоваться придется самим постоянно допиливать этот сервис. И самое важное, пока кажется что кейс со спящим устройствам в любом случае пришлось бы решать на стороне фронта
Насколько я понял идею: смысл идеи в защите от парсинга в том, что вычислять и запоминать браузеры , делающие частые запросы, по фингерпринту и их блокировать. Что будет мешать купить антидетект браузер, настроить в нем 500 профилей, купить к ним 500 мобмльных прокси рф, управлять им по апи, и с каждого делать условно по одному запросу в минуту?
Web-приложение с использованием fingerprint: как это работает и в чем сложность