Да, я обновил пост. Access Denied - т.к. доступ к сервису возможен только из определённых стран. США и Сингапур точно в белом списке. На сайт можно попасть через любой прокси из этих стран.
Какой именно запрос - неизвестно, я исследовал Network log, но так и не смог выяснить.
После первого get-запроса на указанный мною линк уходит второй get-запрос, с типом xhr. Как он формируется и как создать такой же для меня, к сожалению, пока тайна, покрытая мраком..
Lelouch, согласен, толку от масслукинга я не заметил, больше его не использую. Охваты падают - видимо, инстаграм начинает как-то по-другому посты отображать. Возможно, чаще показывает тебя тем людям, истории которых ты просматривал, а им, в общем то, на твой контент пофиг :(
Нет, дело не в MAC-адресе.
У инсты в данном случае вообще доступа к маку нет.
Всё оказалось несколько проще: я не обратил внимание на то, добавляю прокси для http схемы, хотя должен был для https (так как шёл я на https://www.instagram.com), поэтому библиотека requests, не обнаружив прокси с нужной схемой, просто выполняла запрос с моего реального IP.
Что удалось выяснить на данный момент:
1) Действительно, схема была не верной
2) Публичные прокси не годятся для парсинга инсты: из пачки бесплатных прокси (~120 штук), только 5-6 может получить респонс постучавшись на https://www.instagram.com, да и те все\почти все уже забанены.
AlexBoss, так ведь меня бы устроило сохранение куков, если бы там не было моего реального айпишника, а был прокси. Беда то не в том, что они сейвятся. Бан я получаю и без сессии.
Там выше подсказали, что я прокси с неверной схемой использую: http, вместо https. Вполне вероятно, моя проблема возникает из-за этого.
AWEme, хммм... Вот оно что! То есть, requests вместо того, чтобы сказать мне "Чувак, твой прокси невалиден для данного запроса" просто молча идёт на сервер под моим реальным айпи?!
Премного благодарен! Проверю..
AlexBoss, всё правильно. Я для каждого треда я создаю сессию, в хидеры помещаю индивидуальный User Agent, через session.proxies.update добавляю прокси. Я тоже сначала подумал, что каждый тред использует одинаковый инстанс - подебажил через print(id(session)) - объекты, разумеется, разные.
З.Ы. Через requests.get с проксями та же песня - как только инста банит один тред, остальные тут же уходят в нокаут, а значит, разницы, между использованием session.get и requests.get в моём кейсе нет.
Я уже всю камасутру перепробовал, чтобы инсту нагнуть, но пока наоборот..
Пользуюсь вот этой либой https://pypi.org/project/py-proxy/
Просто получаю прокси и в формате {"http": "http://ip:port"} складываю в session.proxies (session - инстанс requests.Session)
После выполняю запрос.
Большое спасибо!
Похоже, я выяснил, в чём проблема.
В cookies каждого объекта session содержится одна и та же строка: <Cookie urlgen="{реальный_IP_моей_машины: порт}
Похоже, именно так Инста и палит меня :)
Буду думать, что с этим можно сделать.
Я про массовый просмотр сториз моей ЦА, чтобы привлечь внимание к своему аккаунту :)
Прогнозируемая конверсия переходов на уровне 8-10%, поэтому смотреть сториз нужно сотнями тысяч в день.
В моей ситуации самое странное то, что как только дохнет один тред, тут же отваливаются и все остальные. То есть, или инстаграм понимает, что любые запросы к постам пользователя, подвергаемого парсингу, приходят от бота, несмотря на разные IP, или я где-то затупил и requests использует IP моей машины, а прокси-адреса игнорит..
pygame, простите, а где можно прочесть о том, что хидеры в вебсокетах - deprecated?
Вот что написано в RFC 6455:
12. The request MAY include any other header fields, for example,
cookies [RFC6265] and/or authentication-related header fields
such as the |Authorization| header field [RFC2616], which are
processed according to documents that define them.
Я не увидел в RFC информации о том, что обслуживание хидеров устарело. Наоборот, написано, что их применение возможно.
А вот авторизационный хидер, да - устарел: https://stackoverflow.com/questions/4361173/http-h...
Vitsliputsli, после вашего коммента погуглил чуть получше и да, действительно, библиотека WebSockets поддерживает хидеры. Сейчас разберусь с тем, как это работает, и, вероятно, проблема решена. Большое вам спасибо! :)
Vitsliputsli, Sanic обрабатывает данный веб-сокет как url. Т.е. внешний адрес сокета получается примерно таким: test.example.com/api/chat/someUserID
Вот в данном урле нельзя передавать какие-либо данные кроме юзер айди
Написано
Войдите на сайт
Чтобы задать вопрос и получить на него квалифицированный ответ.