🕵️‍♂️ Недавно мне пришлось столкнуться с интересным вызовом, парсингом интернет магазина Комус. Метод обхода защиты Qrator, известный мне, перестал работать, а данные нужны заказчику срочно. Но вместо того, чтобы сдаваться, я решил пойти другим путем.

🌐 Сайт любезно предоставляет Sitemap, где есть ссылки на все товары товары, например, такие как эта: komus.ru/katalog/mebel/mebel- ... buk-730kh730kh22-mm-/p/110829/

🤖 Оказалось, что большая часть URL адреса не имеет значения, кроме /p/110829/ Вероятно 110829 это ID товара в базе данных. Эта информация пригодится в будущем.

📱 Но как быть, если обойти Qrator в короткий срок я не могу? Решение пришло с использованием мобильного приложения. Я воспользовался инструментом для обратной инженерии и начал анализировать трафик.

🤯 Авторизация в Firebase, анонимная авторизация на сервере komus через OAuth, а далее запросы
со всеми необходимыми данными подписанные токеном OAuth. Без какой либо защиты. Но здесь возникают сложности. Для успешной авторизации нужно передать "device_id", который состоит из FirebaseID и некой шифрованной части, а также добавить заголовок "X-Komus-Mobileapp". Алгоритм формирования "X-Komus-Mobileapp" мне удалось раскрыть, но "device_id" оставался загадкой.

🔍 Я провел долгие исследования, но так и не смог найти место в котором генерируется нужная мне строка. Окончательно запутавшись в Smali коде связанном с RxJava я написал скрипт на Node.js, который сбрасывает данные приложения, устанавливает прокси и через Frida получает сгенерированный "device_id", после чего завершает процесс приложения, до обращения к серверам komus. Вот у меня и появились ценные "device_id", связанные с прокси.

🌟 API предоставил интересный мне endpoint: /komuswebservices/v1/komus/product/?code=*16 id товаров через запятую*. Я предположил, что в URL товара содержится ID, и моя догадка подтвердилась. Теперь осталось делать запросы с токеном OAuth к этой конечной точке и получить все необходимые данные в удобном формате JSON. И, конечно, важно не перегрузить сервер.

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

#Разработка #Парсинг #ReverseEngineering

🤖💭 Проектная занятость в разработке парсеров: почему это не всегда хорошо?

Привет, друзья! 🚀 Столкнулся с не очень приятной ситуацией в работе и это натолкнуло меня на целую ветку размышлений. Поделюсь с вами почему проектная занятость в разработке парсеров может быть не самым оптимальным вариантом для занятости. Погрузимся в детали! 👇

1️⃣ Недолгосрочность. Разработка парсеров — это несколько этапов, и они могут занять некоторое время. Если вы постоянно переключаетесь с одного проекта на другой, это может мешать глубокому погружению в задачу и созданию качественного продукта.

2️⃣ Сложность задач. Парсеры часто требуют детальной настройки и оптимизации. Если каждый раз вы начинаете с нуля, то можете терять ценное время, изучая новые библиотеки и инструменты.

3️⃣ Отсутствие стабильности. В проектной занятости может не быть гарантии на постоянную работу, что может быть проблемой для финансовой стабильности и планирования.

4️⃣ Потеря экспертизы. Постоянное переключение между разными проектами может мешать накоплению глубокой экспертизы в определенной области.

5️⃣ Риск ошибок. При разработке парсеров часто встречаются тонкие нюансы и ошибки, которые могут быть устранены только при глубоком анализе и долгосрочной работе.

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

Что вы думаете на этот счет? Делитесь своими мыслями и опытом в комментариях! 💬👇 #Разработка #Парсинг #ПроектнаяЗанятость

👉 Одним вечером, когда я листал Телеграм, я задал вопрос в комментариях под одним постом и после получения ответа с несогласием сразу решил проверить, был ли я прав. 🤔

🔍 Я написал парсер и, как я и предполагал, результаты оказались в точности такими, какими я их ожидал.

📝 Сегодня я решил рассказать об этом опыте в небольшой статье.

👉 https://telegra.ph/Parsing-informacii-o-prodavcah-Ozon-10-07

🌐📊 #Разработка #Парсинг #АнализДанных

Многие просили написать о том как я обхожу защиту используя API мобильных приложений. В этой статье постарался на примере рассмотреть как это делается. Буду рад обратной связи в коментах!
https://telegra.ph/Perehvat-trafika-mobilnyh-prilozhenij-11-05

Если кто-то считает, что парсить российские площадки сложно, то попробуйте свои силы на китайских площадках! И не просто Aliexpress или Gearbest, а что-то настояще китайское до мельчайших деталей. Там вы сможете набраться незабываемого опыта... Защита этих площадок поражает своей непредсказуемостью. И если вам понадобится авторизация, будьте готовы запасать аккаунты... Вот это настоящий вызов, а не просто какие-то наши маркетплейсы

Итак. Вряд ли получится выкладывать всё по плану. Разбавлю все парой интересных коротких историй. А сейчас то, что давно просили😅.
https://habr.com/ru/articles/799569/

Один минус в карму я поймал после глупого мема у себя в ТГ. Сколько минусов будет после такого вступления? 😁
https://habr.com/ru/articles/800861/

Спасибо за участие🤗

Меняю отпечатки, решаю челенджы, а оно всё равно знает что я от них хочу

Похоже этот цикл бесконечный...

http://much-data.ru
http://много-данных.рф
Пока что поставил редирект сюда, ещё и по http, но пускай будут. А то через пару лет будут домены qwerqasfasf.ru продовать по овермного) Респект купившему parsing.ru
А вообще есть план на это всё. Данных то реально много копится😅