- Регистрация
- 07.12.2012
- Сообщения
- 35
- Реакции
- 57
- Баллы
- 18
Здравствуйте, уважаемые пользователи!
Все мы время от времени собираем какую либо информацию с различных источников. И чем больше развиваются технологии, тем сложнее защиту ставят их владельцы. Иногда вам нужно спарсить именно защищенные элементы и тогда приходится изловчиться. Возьмем для примера сайт автомобильных объявлений auto.ru и попробуем собрать номера телефонов владельцев объявлений.
Давайте сразу перейдем к сбору телефонов с конкретных объявлений. А для этого начнем анализ с осмотра страницы. Откроем первое объявление: видим, что для получения номера телефона нужно нажать на кнопку "Показать". Прикидываем, что раз это защита от автоматического парсинга, значит номер на странице при первичной загрузке не присутствует, а подгружает откуда-то по клику. Иначе, это была бы защита лишь от дурака.
Давайте посмотрим код кнопочки "Показать". "Какая радость!", - нам даже не придется анализировать javascript! Ссылка указана явным образом прямо в одном из атрибутов. И подметим еще один нюанс - номер объявления(id в строке браузера) подозрительно совпадает с указанным в коде кнопки, но с другим адресом. Скажем так, это очень позитивно, значит как минимум мы сможем собирать просто айдишники, а потом подставлять нужный адрес: либо для открытия объявления, либо для получения номера.
Что теперь делать? А все просто - раз нам дают ссылку, надо по ней перейти! Дописываем домен и в новую вкладку. Оп, опять очень душевная картина - нам в формате JSON в открытом виде дают номер телефона, да еще и 2 штуки(рабочий и мобильный). Какая мысль нас посещает первой в такой ситуации? Правильно - парсим айдишки объявлений, подставляем к ссылке с get_phones и забираем телефоны.
Так я и сделал в сам начале. Пишем шаблон, который делает простой GET-запрос на страницу и собирает информацию через RegEx.
Однако, уже после первых запусков я понял, что явно что-то упускаю - начинает приходить несуразный ответ вроде этого:
Он как бы явно нам намекает, что фиг вам номер, вот вам капча. Значит простой пробег по ссылкам не сработает.
Итак, нам нужно понять в чем же дело.
Давайте посмотрим через плагин WebDeveloper для Chrome, что у нас имеется в кукисах для данного домена. Наблюдает наличие 4-х кукисов.
Давайте почистим их опять же тем же плагином и посмотрим как они себя ведут. В идеале мы их сохраним и будем подставлять в GET-запросе каждого из номеров.
Важно: после удаления кукисов не закрываем страницу со списком объявлений, чтобы было откуда брать ссылки на объявления. Теперь открываем новую вкладку и копируем туда первую ссылку из списка, предварительно открыв инструменты разработчика, а точнее раздел Network. Будем смотреть что происходит.
Вот она новая вкладка, открытая после очистки кукисов. GET-запрос на HTML страницу был всего 1 - его и открываем. Смотрим, что пришло во вкладке Cookies.
Во-первых, обращаем внимание на то, что мы при загрузке страницы кукисов не посылали, т.к. набор Request_Cookies пуст. Все кукисы, что мы видим - пришли нам в ответе(Responce_Cookies).
В итоге у нас 4 куки, а на самом деле 5, т.к. 2 из них повторяются, а значит результирующая всего 1. Какая наша первая мысль? Правильно, собрать эти куки и запрос на номер телефона делать уже с подстановкой этих кукисов.
Если переключиться на вкладку Headers, увидим как кукисы приходят к нам в браузер - то есть через ответ сервера прямо в хедере.
Но если присмотреться, то из 4-х кукисов всего 1 простой со значением "1". Остальные представляют собой какие-то сложные id. Надо проверить, вдруг они меняются, а то нас опять вычислять и дадут капчу.
Тогда не трогая эту вкладку (не закрываем), опять открываем свежую (кукисы уже не удаляем) и копируем туда вторую ссылку из списка. Смотрим кукисы также, как и в первый раз. Момент первый - Request_Cookies на сервер ушли те самые куки, которые нам пришли с сервера при загрузке первого объявления. Момент второй и радостный - новых параметров не добавилось. Момент третий - нам пришли новые кукисы, призванные переписать старые значения уже имеющихся параметров на новые.
___suid явно изменился целиком, а вот в cvcs в конец добавили еще 2 значения, разделенных точкой, а первые 2 так и остались. Запоминаем все это и вновь повторяем операцию.
Опять пришли новые куки, старые у нас приняли и в cvcs опять докинули 2 новых параметра в конец.
Еще разок.
И еще. После стольких операций начинает доходить вот что: раз каждый новый запрос пристыковывает к старому значению cvcs новые символы, значит старые ему зачем-то тоже нужны. Логично предположить, что таким образом хранится история посещений. То есть на данном этапе мы имеем 5 посещенных страниц, и админы сайта явно знают какие и в каком порядке. А теперь вспомним про прекрасное ограничение в 4Кб на размер куки. Значит история у них должна когда-нибудь обрываться. Напряжемся и откроем еще пару объявлений.
И вот тут видим замечательную картину: нашему значению уже не просто добавили 2 набора в конец, а сделали поразрядный сдвиг влево, вытеснив наши 2 самых старых набора символов. Делаем вывод - данный параметр работает по принципу "Первый вошел - первый вышел" и максимум хранит 10 значений, а за раз их приходит всегда 2. Попутно замечаем, что 2 параметра абсолютно стабильны: cookie_test и autoru_sid. А suid просто меняется каждый раз целиком. Все это может пригодиться, но не факт.
Теперь мы можем сделать вполне конкретный вывод - для того, чтобы гулять по сайту "легально", мы должны будем обновлять приходящими куками старые значения и подавать их в GET-запрос. Тогда сам по себе браузер нам будет вовсе не нужен.
Теперь давайте посмотрим, как отражается запрос номера на кукисах.
Возьмем любое объявление и кликнем на "Получить номер" с открытой вкладкой Network. Кукисов в ответе сервера приходит еще меньше, всего 1 параметр. И уже нам знакомый и опять в виде 2-х наборов.
Запоминаем - чтобы наши походы по страницам сайта были похожи на обычные браузерные, нам необходимо:
Схема нам стала вроде бы понятна и можно приступить к написанию шаблона. Алгоритм такой:
1. Грузим первое объявление
2. Сохраняем его куки
3. Просим у него же номер
4. Обновляем куки
5. Берем следующее объявление
6. Обновляем куки
7. Бером номер
8. Обновляем куки
и т.д.
Доделав шаблон до данной схемы я протестил сбор вновь. Результаты мне понравились - номера собираются.
Однако, если сменить IP или собрать подряд объявлений 20 опять приходит капча. Данный шаблон я также приложу для скачивания, чтобы был ясен ход рассуждений поэтапно.
Позже, мне удалось понять в чем дело. Радость была абсолютно преждевременной - шаблон работал лишь потому, что мой IP после введения капчи не в ZennoPoster видимо попал на время в "белый список". Как только я его меняю - мне с первого же объявления дают капчу.
Выглядит странно, объясню почему. Допустим я новый посетитель и первый раз в жизни с этого компьютера захожу на данный сайт. По опыту - каждый новый посетитель по умолчанию "хороший", а значит ему можно все. Это закон web usability (иначе бы никто таким сайтом не пользовался). Тогда почему мне сразу же дают капчу? Вариант лишь один - мой запрос явным образом дает понять, что я "плохой" посетитель, а то и вовсе робот-парсер. Теперь наша задача выглядить так: понять, как он нас палит и как его обдурить.
Варианты
IP - не вариант, тестил. Браузер - не вариант, перебрал и UserAgent и десктопные. Куки - вроде уже пробовали и собирать и подменять.
Тогда предпримем самое простое - зайдем на страницу объявления через ZennoPoster экшн (то есть уже не через Get-запрос, а как бы в браузере) и сохраним кукисы через C#.
Забегая вперед, скажу, что параметр true вернет их в режиме строчки, а замену я делаю для удобства использования в дальнейшем. Смотрим, что у нас вышло в переменной FullCookie.
Смотрим, а там опять знакомые нам параметры:
И тут доперает - они же после капчи должны как-то нас верифицировать, чтобы потом повторно не выдавать капчу на каждом объявлении? Должны. Но куки чот не меняют свою структуру.
Тогда давайте нарвемся на капчу и посмотрим, что окажется в кукисах ZennoPoster после этого. Чтобы потом это не повторять, записываем все действия в зенке в шаблон.
А теперь, внимание, кука после подтверждения капчи:
Классно? Мало того, что за нами теперь следить Яндекс, так нам еще и меток напихали.
Почему так случилось? Очень просто - второй способ обработки куки (который не в ответе сервера) - это добавление/модификация куки через JavaScript на стороне клиента(в браузере). То есть какой-то из скриптов после рендеринга кода страницы заполняет нам дополнительные кукисы. И по всей видимости такую куку добавляет нам Яндекс (возможно Метрика). И она то и является решающей.
Тогда берем эту куку и подставляем в нее новые значения динамических полей ___suid и cvsc, а остальные не трогаем и пробуем погонять по объявлениям.
Результат себя оправдал - можно долго парсить номера и горя не знать. То есть теперь мы себя опознаем как "хороший" юзер, подтвердивший себя капчей, и нам дают спокойно кликать по номерам без капчи.
Все мы время от времени собираем какую либо информацию с различных источников. И чем больше развиваются технологии, тем сложнее защиту ставят их владельцы. Иногда вам нужно спарсить именно защищенные элементы и тогда приходится изловчиться. Возьмем для примера сайт автомобильных объявлений auto.ru и попробуем собрать номера телефонов владельцев объявлений.
Приступим. Для начала зайдем на сайт объявлений в любую категорию. Видим, что как минимум удобно будет парсить список объявлений, т.к. их много на странице и они кликабельны. Соберем все ссылки из категории,а потом отдельным шаблоном будем уже обрабатывать каждое из объявлений. Сам парсер списка объявлений со страницы описывать, пожалуй, не будем - не интересный шаблон и очень простой.
Что теперь делать? А все просто - раз нам дают ссылку, надо по ней перейти! Дописываем домен и в новую вкладку. Оп, опять очень душевная картина - нам в формате JSON в открытом виде дают номер телефона, да еще и 2 штуки(рабочий и мобильный). Какая мысль нас посещает первой в такой ситуации? Правильно - парсим айдишки объявлений, подставляем к ссылке с get_phones и забираем телефоны.
Однако, уже после первых запусков я понял, что явно что-то упускаю - начинает приходить несуразный ответ вроде этого:
Код:
{"result":false,"errors":["\u041d\u0435\u043e\u0431\u0445\u043e\u0434\u0438\u043c\u043e \u043f\u0440\u043e\u0439\u0442\u0438 \u0437\u0430\u0449\u0438\u0442\u0443 \u043e\u0442 \u0440\u043e\u0431\u043e\u0442\u043e\u0432"],"data":{"captcha_redirect":"http:\/\/captcha.auto.ru\/"}}Он как бы явно нам намекает, что фиг вам номер, вот вам капча. Значит простой пробег по ссылкам не сработает.
Итак, нам нужно понять в чем же дело.
Давайте посмотрим через плагин WebDeveloper для Chrome, что у нас имеется в кукисах для данного домена. Наблюдает наличие 4-х кукисов.
Давайте почистим их опять же тем же плагином и посмотрим как они себя ведут. В идеале мы их сохраним и будем подставлять в GET-запросе каждого из номеров.
Важно: после удаления кукисов не закрываем страницу со списком объявлений, чтобы было откуда брать ссылки на объявления. Теперь открываем новую вкладку и копируем туда первую ссылку из списка, предварительно открыв инструменты разработчика, а точнее раздел Network. Будем смотреть что происходит.
Вот она новая вкладка, открытая после очистки кукисов. GET-запрос на HTML страницу был всего 1 - его и открываем. Смотрим, что пришло во вкладке Cookies.
Во-первых, обращаем внимание на то, что мы при загрузке страницы кукисов не посылали, т.к. набор Request_Cookies пуст. Все кукисы, что мы видим - пришли нам в ответе(Responce_Cookies).
В итоге у нас 4 куки, а на самом деле 5, т.к. 2 из них повторяются, а значит результирующая всего 1. Какая наша первая мысль? Правильно, собрать эти куки и запрос на номер телефона делать уже с подстановкой этих кукисов.
Но если присмотреться, то из 4-х кукисов всего 1 простой со значением "1". Остальные представляют собой какие-то сложные id. Надо проверить, вдруг они меняются, а то нас опять вычислять и дадут капчу.
Тогда не трогая эту вкладку (не закрываем), опять открываем свежую (кукисы уже не удаляем) и копируем туда вторую ссылку из списка. Смотрим кукисы также, как и в первый раз. Момент первый - Request_Cookies на сервер ушли те самые куки, которые нам пришли с сервера при загрузке первого объявления. Момент второй и радостный - новых параметров не добавилось. Момент третий - нам пришли новые кукисы, призванные переписать старые значения уже имеющихся параметров на новые.
___suid явно изменился целиком, а вот в cvcs в конец добавили еще 2 значения, разделенных точкой, а первые 2 так и остались. Запоминаем все это и вновь повторяем операцию.
Опять пришли новые куки, старые у нас приняли и в cvcs опять докинули 2 новых параметра в конец.
Еще разок.
И еще. После стольких операций начинает доходить вот что: раз каждый новый запрос пристыковывает к старому значению cvcs новые символы, значит старые ему зачем-то тоже нужны. Логично предположить, что таким образом хранится история посещений. То есть на данном этапе мы имеем 5 посещенных страниц, и админы сайта явно знают какие и в каком порядке. А теперь вспомним про прекрасное ограничение в 4Кб на размер куки. Значит история у них должна когда-нибудь обрываться. Напряжемся и откроем еще пару объявлений.
И вот тут видим замечательную картину: нашему значению уже не просто добавили 2 набора в конец, а сделали поразрядный сдвиг влево, вытеснив наши 2 самых старых набора символов. Делаем вывод - данный параметр работает по принципу "Первый вошел - первый вышел" и максимум хранит 10 значений, а за раз их приходит всегда 2. Попутно замечаем, что 2 параметра абсолютно стабильны: cookie_test и autoru_sid. А suid просто меняется каждый раз целиком. Все это может пригодиться, но не факт.
Теперь мы можем сделать вполне конкретный вывод - для того, чтобы гулять по сайту "легально", мы должны будем обновлять приходящими куками старые значения и подавать их в GET-запрос. Тогда сам по себе браузер нам будет вовсе не нужен.
Теперь давайте посмотрим, как отражается запрос номера на кукисах.
Возьмем любое объявление и кликнем на "Получить номер" с открытой вкладкой Network. Кукисов в ответе сервера приходит еще меньше, всего 1 параметр. И уже нам знакомый и опять в виде 2-х наборов.
Запоминаем - чтобы наши походы по страницам сайта были похожи на обычные браузерные, нам необходимо:
- Листать сами объявления. То есть обязательно заходить сначала на страницу объявления, а потом уже запрашивать номер. Ведь раз у нас в явном виде есть ссылки на все номера, вроде как хочется просто пройтись по номерам, опуская сами объявления. Но тогда нас быстро вычислять по кукисам, ведь наши запросы будут проходить как бы минуя 2 набора сессий, получаемых со страницы самого объявления.
- Все кукисы нам необходимо запоминать и обновлять перед посещением каждой следующей страницы - ведь запрос номера тоже меняет куки и засчитывается как посещение!
Схема нам стала вроде бы понятна и можно приступить к написанию шаблона. Алгоритм такой:
1. Грузим первое объявление
2. Сохраняем его куки
3. Просим у него же номер
4. Обновляем куки
5. Берем следующее объявление
6. Обновляем куки
7. Бером номер
8. Обновляем куки
и т.д.
Доделав шаблон до данной схемы я протестил сбор вновь. Результаты мне понравились - номера собираются.
Однако, если сменить IP или собрать подряд объявлений 20 опять приходит капча. Данный шаблон я также приложу для скачивания, чтобы был ясен ход рассуждений поэтапно.
Позже, мне удалось понять в чем дело. Радость была абсолютно преждевременной - шаблон работал лишь потому, что мой IP после введения капчи не в ZennoPoster видимо попал на время в "белый список". Как только я его меняю - мне с первого же объявления дают капчу.
Выглядит странно, объясню почему. Допустим я новый посетитель и первый раз в жизни с этого компьютера захожу на данный сайт. По опыту - каждый новый посетитель по умолчанию "хороший", а значит ему можно все. Это закон web usability (иначе бы никто таким сайтом не пользовался). Тогда почему мне сразу же дают капчу? Вариант лишь один - мой запрос явным образом дает понять, что я "плохой" посетитель, а то и вовсе робот-парсер. Теперь наша задача выглядить так: понять, как он нас палит и как его обдурить.
Варианты
IP - не вариант, тестил. Браузер - не вариант, перебрал и UserAgent и десктопные. Куки - вроде уже пробовали и собирать и подменять.
Тогда предпримем самое простое - зайдем на страницу объявления через ZennoPoster экшн (то есть уже не через Get-запрос, а как бы в браузере) и сохраним кукисы через C#.
Забегая вперед, скажу, что параметр true вернет их в режиме строчки, а замену я делаю для удобства использования в дальнейшем. Смотрим, что у нас вышло в переменной FullCookie.
Смотрим, а там опять знакомые нам параметры:
И тут доперает - они же после капчи должны как-то нас верифицировать, чтобы потом повторно не выдавать капчу на каждом объявлении? Должны. Но куки чот не меняют свою структуру.
Тогда давайте нарвемся на капчу и посмотрим, что окажется в кукисах ZennoPoster после этого. Чтобы потом это не повторять, записываем все действия в зенке в шаблон.
А теперь, внимание, кука после подтверждения капчи:
Классно? Мало того, что за нами теперь следить Яндекс, так нам еще и меток напихали.
Почему так случилось? Очень просто - второй способ обработки куки (который не в ответе сервера) - это добавление/модификация куки через JavaScript на стороне клиента(в браузере). То есть какой-то из скриптов после рендеринга кода страницы заполняет нам дополнительные кукисы. И по всей видимости такую куку добавляет нам Яндекс (возможно Метрика). И она то и является решающей.
Тогда берем эту куку и подставляем в нее новые значения динамических полей ___suid и cvsc, а остальные не трогаем и пробуем погонять по объявлениям.
Результат себя оправдал - можно долго парсить номера и горя не знать. То есть теперь мы себя опознаем как "хороший" юзер, подтвердивший себя капчей, и нам дают спокойно кликать по номерам без капчи.
- Номер конкурса статей
- Третий конкурс статей
- Тема статьи
- Парсинг
Последнее редактирование:
