BAS - элементарный Proxy Checker на http запросах (Часть первая)
мануал для новичков и тех "хардскилл профи", что клепают "софт" на заказ с использованием эмуляции
*******************************
Всем доброго времени суток. Данный мануал является частью большой статьи, которую я разделю на несколько тем, дабы поэтапно взглянуть на разработку софта в Browser Automation Studio без использования эмуляции. В последней теме мы напишем софт, который придется по вкусу всем любителям халявы и не только. Ну что, приступим?
Разбивка по темам (ссылки будут обновляться по мере выхода статей)
- BAS - элементарный Proxy Checker на http запросах [Pt.1]
- BAS - элементарный Proxy Checker на http запросах [Pt.2]
- Название темы отсутствует
- Заключительный этап + софт под который нам нужен был прокси чекер
На днях мне захотелось написать статью + софт, которые, по моему скромному мнению, будут полезны многим форумчанам, в особенности новичкам и тем «супер-профи», что клеят баннеры с рекламой услуг разработки на BAS’е о том, что они могут взяться за разработку софта любой сложности, а потом дописывают «без http». Скажу сразу, я ни в коем случае, не считаю себя каким-то гуру-разработчиком в этом тетрисе под названием БАС, но в последнее время ко мне очень часто обращаются люди с просьбой подправить чужой софт (если вообще это возможно назвать софтом). В большинстве случаев ноги растут с данного борда. Перелопатив кучу эмуляционных выкидышей, плюс дикое желание написать софт со статьей подтолкнули меня на создание этой романтической эпопеи.
Browser Automation Studio является довольно сильным инструментом разработки не только для автоматизации действий в браузере, но и для написания софта, никак не связанного с браузерами. Тут тебе работа и с таблицами, и с текстовыми документами, и с картинками и всевозможными языками программирования благодаря установке кастомных модулей + встроенной ноде (NodeJS). Но, несмотря на огромный функционал, многие так и не заходят дальше простой эмуляции. Оно и понятно. Все сложилось так, что накидывать кубики куда проще, чем изучать всевозможные средства защиты на сайтах, методы обхода этих защит и уж тем более чертовы http запросы. Кстати, что вообще это за запросы такие и на кой-ляд они нам нужны?
Http — это клиент-серверный протокол обмена данными. Этот хитрый зверёк создает общение между клиентом и сервером посредством текстовых обращений, но при этом он может передавать через текст различные медиафайлы, будь то картинки, видео или любые другие файлы.
В http запросах всегда имеются две стороны: отправитель и получатель. В большинстве случаев изначально отправителем является сам человек, сидящий за компьютером, игровой приставкой, телефоном и т. д. Кто-то скажет, что это все бред и он ничего не отправляет и ни о каких отправленных запросах он не знает. И отчасти он будет прав, ведь современный интернет шагнул настолько далеко, что обычному рядовому пользователю не нужно париться ни о чем, кликнул по нужной ссылке или кнопке, и все работает само. Но на самом деле все, что мы видим в интернете — это внешняя оболочка, разноцветный фантик, пестрящий набором текста, цветов, картинок и рекламы. За этой самой оболочкой кроется другая сторона — тёмная. Сторона скриптов, запросов и целого моря слёз бэкенд-разработчиков. Давайте взглянем на самый элементарный пример работы http. Сейчас вы находитесь на сайте, но как вы сюда попали? Элементарная загрузка сайта для нас выглядит следующим образом: открываем браузер, вводим адрес сайта site.name в поисковую строку и жмем enter. Но что же происходит на самом деле? А на самом деле происходит следующее: после ввода адреса сайта браузер формирует стандартный запрос на сервер этого самого сайта. Стандартный запрос может выглядеть следующим образом:
GET https://site.name/ HTTP/1.1
Host: site.name
Connection: keep-alive
Cache-Control: max-age=0
sec-ch-ua: "Chromium";v="106", "Yandex";v="22", "Not;A=Brand";v="99"
sec-ch-ua-mobile: ?0
sec-ch-ua-platform: "Windows"
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/106.0.0.0 YaBrowser/22.11.5.715 Yowser/2.5 Safari/537.36
Accept:text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
Sec-Fetch-Site: none
Sec-Fetch-Mode: navigate
Sec-Fetch-User: ?1
Sec-Fetch-Dest: document
Accept-Encoding: gzip, deflate, br
Accept-Language: ru,en;q=0.9
Refer: site.name
Cookies: mid: oH737fJvjkasrjns; jGr9oe26gnZRieg;73287hfinvnksdnv;Выглядит страшно, неправда ли? Давайте разбираться! При первом взгляде на это все создается ощущение, что это очередная сложная и малоизвестная фигня. Но данный зверь на самом деле куда безобиднее, чем кажется. Http состоит из самого запроса + его метода (GET https://site.name/ HTTP/1.1) и так называемых заголовков (все остальное ниже первой строки). В самом запросе указывается его метод. В 90% случаев, это либо GET, либо POST. Всего насчитывается 9 методов (GET, POST, CONNECT, OPTIONS HEAD, PATCH, PUT, DELETE, TRACE). Не стоит волноваться, если вы сейчас не понимаете что означают все эти слова. Для того чтобы разобраться в назначении запросов, достаточно их перевести с английского языка. Мы не будем углубляться во все запросы, а остановимся на основных. В переводе с английского «GET» означает «получать». Этот метод отвечает за отображение страниц сайтов, когда мы пытаемся на них зайти. POST — это отправление. Именно этот метод отвечает за данные, которые мы отправляем на сайт, например, когда мы вводим логин и пароль на сайте, а потом нажимаем кнопку «войти», GET перед https://site.name/ HTTP/1.1 заменяется на POST, и запрос выглядит следующим образом: POST https://site.name/ HTTP/1.1. Также при post-запросе скорее всего к адресу сайта добавится атрибут или страница, к которой мы обращаемся, например: POST https://site.name/authorization HTTP/1.1 или POST https://site.name/login HTTP/1.1.
Теперь давайте разберемся, что же находится ниже запроса и его метода. А дальше у нас расположены так называемые «заголовки». Заголовки бывают обязательные и необязательные. Необязательные заголовки так и называются, потому что их можно не указывать в запросе, но очень часто они помогают серверам понять, как более правильно отобразить для нас информацию на сайте. Например, таким необязательным параметром может быть разрешение экрана. Современные сайты сами умеют определять границы браузера и адаптировать свое содержимое под нужный размер. Также в заголовках могут указываться сайты, с которых мы делаем запрос, за это отвечает заголовок «Refer». Если бы мы заходили на сайт из поисковика, например, из гугла, то данный заголовок выглядел бы так: Referer: google.com. Еще в заголовках передаётся язык, установленный в нашей системе по умолчанию, файлы куки и многое другое.
Мы поверхностно взглянули на http запросы, и хоть эта тема куда обширнее и изучать ее можно и нужно более подробно, нам будет достаточно уже имеющихся знаний, ведь данный проект не потребует от нас каких-то сверхсекретных знаний. Суть проекта заключается в том, что в конечной статье для написания софта нам потребуются прокси и дабы у нас не было лишних затрат, ведь конечный проект подразумевает халяву, мы сможем получить прокси совершенно бесплатно. К тому же в данном проекте будут самые простые запросы и они помогут нам постепенно перейти к более сложным моментам. Изначально я хотел, чтобы мы сами собирали списки прокси и загружали их в проект, но потом подумал, раз уж речь идет о БАС’е, задействуем ту самую автоматизацию, под которую и был создан БАС. На данный момент мы имеем следующие вводные данные: нам потребуется где-то взять список прокси, загрузить их в наш проект, проверить на работоспособность, сохранить рабочие прокси и реализовать все это на http запросах, ведь они работают куда быстрее, чем браузерная эмуляция, и создают куда меньшую нагрузку на систему. Пошарив в интернете, выбор пал на данный сайт ТЫК (не реклама). Выбор на этот сайт пал, потому что здесь хоть и есть некий способ защиты в виде csrf-токена, но обойти его будет очень легко. К тому же, с этим сайтом не все так просто! Что же в нем такого, вы узнаете в ходе прочтения данной статьи. Теперь все готово, приступаем к написанию проекта.
Запускаем бас, создаем новый проект proxychecker. Для сохранения наших рабочих прокси нам потребуется создать ресурс под названием «proxy», тип из файла, далее ставим галочки на чтение и удаление после использования, каждый элемент использовать один раз и с новой строки. После создания ресурса нажимаем на него правой кнопкой, выбираем «редактировать», листаем в самый низ, ставим галочку «Обновлять» и значение «1000». Наша тысяча — это количество миллисекунд, через которое скрипт будет переподгружать данный ресурс обратно в скрипт. Кстати, советую привыкать: все, что связано с действиями через время, в басе рассчитывается в миллисекундах.
Справка: 1 секунда = 1000 миллисекунд .
После этого создадим на рабочем столе папку с одноименным названием проекта. В папке создадим файл с расширением .txt. Я назову файл «goods». Запускаем режим записи, добавляем наш файл в ресурс и жмем «ок».
Режим записи включен, а это значит, что нас интересует модуль http — клиент.
Заходим в него. Разработчики баса о нас позаботились и уже разбили весь модуль на нужные функции, а сами функции были структурированы.
У нас есть отдельная строка под url, отдельная строка под заголовки и меню выбора метода запроса. Приступаем к добавлению. В первую очередь нам нужно загрузить сам сайт, следовательно, нам нужно получить его разметку. Возвращаясь к предыдущему пункту, смотрим на список методов. Получить — это GET. Значит, нам необходимо выбрать «GET — запрос». Наш гет запрос будет выглядеть следующим образом:
GET https://take-proxy.com/ HTTP/1.1
Host: take-proxy.com
Connection: keep-alive
Cache-Control: max-age=0
sec-ch-ua: "Chromium";v="106", "Yandex";v="22", "Not;A=Brand";v="99"
sec-ch-ua-mobile: ?0
sec-ch-ua-platform: "Windows"
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/106.0.0.0 YaBrowser/22.11.5.715 Yowser/2.5 Safari/537.36
Accept:text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
Sec-Fetch-Site: cross-site
Sec-Fetch-Mode: navigate
Sec-Fetch-User: ?1
Sec-Fetch-Dest: document
Referer:https://yandex.ru/
Accept-Encoding: *
Accept-Language: ru,en;q=0.9В самом басе это будет выглядеть так:
Сразу обратим внимание, что в url мы вписываем только адрес сайта, указывать версию клиента (HTTP/1.1) не обязательно, бас сделает это за нас.
Нажимаем «добавить и выполнить». У нас сразу же открывается окно с анализом наших http запросов. Не закрываем его, т. к. это окно понадобится нам для отслеживания статуса запроса. Проверяем, что нам показывает анализ. Во вкладке «Получено» отображается разметка сайта, а статус-код равен 200. Отлично, наш первый успешный запрос!
Следующее наше действие я рекомендую выполнять всегда после получения разметки сайта — это открыть данный сайт в нашем браузере. Заходим на сайт и сразу же жмем «F12». У нас открывается DevTools. Данный инструмент создан специально для анализа, исследований сайтов и их тестирования. Через него мы можем посмотреть, какие стили использует сайт, какие скрипты есть на сайте, а также глянуть еще кучу всего. В разделе «консоль» можно запускать всевозможные скрипты прямо из браузера на странице сайта.
DevTools открыт, теперь выполним то самое обязательное действие после первого запроса. Открываем вкладку «Elements» и запускаем поиск нажатием «Ctrl+F». В поиск вводим слово «token». Как я говорил ранее, у данного сайта есть небольшая защита, она расположена на кнопке «Скачать прокси-лист». Защита представляет из себя генерируемый при каждом подключении csrf-token. Поиск сразу же находит его местоположение и подсвечивает элемент разметки. Обычно такие токены находятся в заголовках сайтов (раздел разметки «title») или прячутся в самом конце страницы, но в нашем случае он на кнопке. Рядом с самим словом «токен» мы можем увидеть его значение. Чаще всего это набор букв разного регистра с цифрами. Заметьте, так как открытая страница в браузере и наш первый гет-запрос это два разных подключения, то и токены у нас будут разные.
Для того чтобы скачать прокси-лист, предоставленный сайтом, нам необходимо уметь извлекать значение данного токена после первого гет-запроса. Для этого нам нужно знать расположение токена в html сайта, а также воспользоваться регулярным выражением для получения самого значения и отсеивания лишнего. Как же нам узнать расположение токена? Все просто! В этом нам поможет DevTools. Кликаем правой кнопкой мышки по строке с нашим токеном, выбираем «копировать» и далее выбираем, что нам нужно скопировать. Мы можем скопировать путь, стиль элемента, его код и т. д. Нас интересует разметка сайта, а значит это XPatch.
У XPatch’а есть два варианта копирования: простой и полный путь XPatch. Так как у данного сайта простая разметка, нет сложных элементов и кучи вложений, нам подойдет простой путь. Выбираем его.
Теперь, так как разметка страницы уже загружена в наш http-клиент благодаря нашему первому GET-запросу, нам не нужно получать страницу по-новой, следовательно, мы сразу можем применить скопированные данные.
ВАЖНО: не забывайте, что такие функции, как «получить содержимое ответа», «получить статус ответа», «применить XPatch» и т. д., ПРИМЕНЯЮТСЯ К ПОСЛЕДНЕМУ СОВЕРШЕННОМУ НАМИ ЗАПРОСУ ВНЕ ЗАВИСИМОСТИ ОТ СТАТУСА И РЕЗУЛЬТАТА НАШЕГО ПОСЛЕДНЕГО ЗАПРОСА!
Так как мы двигаемся по порядку и предыдущий запрос удовлетворяет нашим требованиям, мы идем в модуль http-клиента и выбираем действие «XPatch получить XML». В строку запроса вставляем то, что скопировали из DevTools. Заодно изменим название переменной, в которую все сохранится, назовем ее «XPATH_TOKEN».
XPatch-код , который мы скопировали в браузере:
/html/body/div[1]/main/div/div/div[2]/form/inputЖмем «ок» и в списке переменных появляется наша переменная с кодом элемента и нашим токеном. Теперь нам необходимо выдернуть значение токена из разметки страницы.
Для обрезания всего лишнего и сохранения только самого токена воспользуемся регулярными выражениями. Как их еще называют в народе — «регулярки», служат они как раз для того, чтобы извлекать всевозможные меняющиеся данные из различных разметок, в нашем случае — из куска html кода, который мы выдернули с сайта. Чтобы создать регулярные выражения воспользуемся соответствующим конструктором. Данный конструктор можно открыть напрямую из баса: Инструменты — Конструктор регулярных выражений.
Как составлять регулярные выражения, я не буду рассказывать, т. к. это отдельная тема. В вики баса и на ютубе есть множество материала по регуляркам. В них нет ничего сложного. Единственное, что я добавлю, — регулярки очень сильно помогают извлекать коды подтверждения из писем на электронную почту, мы будем пользоваться ими для получения кодов в заключительной статье по данной теме. От себя я сразу вставлю нужное нам регулярное выражение:
<input\ type="hidden"\ name="_token"\ value="([\s\S]+)"/>Это значение нам нужно применить в соответствующем модуле из баса «регулярные выражения». Выбираем действие «первое вхождение» и вставляем данные: Строка Для Применения Регулярного Выражения — это наша переменная XPATCH_TOKEN, само регулярное выражение — это код, указанный выше, Извлеченные группы мы удаляем, т. к. их стандартно три штуки, и вместо них вписываем удобную для нас переменную — TOKEN. Данное действие применит наше выражение, извлечет код и запишет его в переменную TOKEN. Добавляем, выполняем, смотрим, что получилось.
Теперь у нас есть токен. Так как сайт сам генерирует текстовый файл со списком всех опубликованных прокси, нам нужно просто его скачать через http-клиент с подставлением нашего токена. Здесь сразу несколько интересных моментов:
1) Как скачиваем и куда? У нас есть несколько вариантов:
— Мы можем скачать файл на наш компьютер через одноименное действие в http-клиенте, потом создать еще один ресурс, перезагрузить скрипт, в него загрузить этот файл, потом прочитать данный файл в БАС’е и уже работать с ним. Но так слишком много действий, которые нам не нужны + я обещал задействовать автоматизацию.
— Вариант с автоматизацией: плюнуть на все, что мы делали до этого, кроме первого запроса и парсить список с сайта построчно. Но это будет еще хуже, чем если бы мы просто скачали файл, к тому же, дойдя до конца первой страницы, нам придется идти на вторую и т. д., пока список не кончится. Помимо лишней обработки действий, как вы думаете, на какой странице нам это надоест? На 2? На 5? На 20? Поэтому мы идем к самому верному и поистине автоматизированному решению.
— Нам нужно получить содержимое файла, который для нас сгенерирует сайт, но при этом не скачивать его. Звучит интересно, неправда ли? Дальше увидим, как это сделать.
2) Второй интересный момент заключается в том, что нам нужно скачать файл. То есть нам нужно его «получить», а это GET-запрос. Мы могли бы скопировать url, на который ссылается данный кликабельный элемент. Но вернитесь в то место, где мы копировали XPatch путь до нашего токена. Посмотрите на сам путь, ничего не замечаете? Наша кнопка оказалось вовсе и не кнопкой. Парадокс! У кнопки стоит определение ввода. Скорее всего, при нажатии на кнопку сайт сам вставляет наш токен в нужное поле и уже потом генерирует файл с прокси-листом.
Мы видим кнопку, а сайт видит ее как ввод текста, следовательно, мы будем не кликать и получать данные, а вводить и отправлять их.
Ввод любых данных (будь то картинка, текст, видео или любой другой файл) - это POST запрос. Давайте же сделаем его!
Заходим в модуль http-клиент, на этот раз выбираем POST-запрос. Как мы видим, это действие у нас немного отличается от GET-запроса. Как минимум, у нас появилось еще одно поле для ввода под названием "PostData". Именно сюда вставляются те данные, которые мы будем отправлять на сайт. Теперь сложим 2+2=5000 и сделаем вывод: на сайте есть поле для ввода, которое замаскировано под кнопку. Если мы открываем сайт в браузере, то мы не получаем никаких значений для ввода в это поле, следовательно, это что-то невидимое, что-то скрытое от глаз простых пользователей и это "что-то" вводит сам сайт. Теперь мы взглянем на наши блоки действий в БАС'е. Из всех проделанных действий мы извлекли лишь саму страницу (вернее ее разметку) и получили токен. Больше никаких данных у нас нет. А как уже говорилось ранее, 2+2=5000, значит будем вводить в нашу псевдокнопку этот токен.
Наш POST-запрос в его естественном виде выглядел бы следующим образом:
POST https://take-proxy.com/free-proxies/list HTTP/1.1
Host: take-proxy.com
Connection: keep-alive
Content-Length: 47
Cache-Control: max-age=0
sec-ch-ua: "Chromium";v="106", "Yandex";v="22", "Not;A=Brand";v="99"
sec-ch-ua-mobile: ?0
sec-ch-ua-platform: "Windows"
Upgrade-Insecure-Requests: 1
Origin: https://take-proxy.com
Content-Type: application/x-www-form-urlencoded
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/106.0.0.0 YaBrowser/22.11.5.715 Yowser/2.5 Safari/537.36
Accept:text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
Sec-Fetch-Site: same-origin
Sec-Fetch-Mode: navigate
Sec-Fetch-User: ?1
Sec-Fetch-Dest: document
Referer: https://take-proxy.com/
Accept-Encoding: gzip, deflate, br
Accept-Language: ru,en;q=0.9
_token=ueHFnw27hnf
В стандартном виде запроса данные, которые нам нужно отправить (они же PostData), вводятся через одну пропущенную строку. Но разработчики БАС’а опять-таки позаботились о нас и добавили для этого отдельное поле. На этом моменте вернемся обратно в браузер и глянем, как записан наш токен.
Как мы видим, он записан через нижнее подчеркивание. Заодно смотрим, на какой адрес ведет нас эта чудо-кнопка. А ведет она нас на /free-proxies/list. А следом указан и наш POST-метод. Следовательно, мы на верном пути! Добавляем наш POST-запрос. В поле PostData вписываем имя переменной с сайта (_token), ставим знак «=» и вместо значения добавляем переменную, в которой мы храним это значение (переменная TOKEN). Получаем следующего вида действие:
Запрос выполнен, статус 200. Заострим внимание на анализаторе трафика. В разделе «Отправлено» появился новый заголовок — Cookies. До этого момента я специально вырезал куки из наших запросов, ибо на сайте нет авторизации, нет каптчи и прочих вещей. Но здесь http-клиент сам по доброй воле передал наши кукисы сайту. Это относится к нашей с вами безопасности в интернете, волей не волей, но так создается наш цифровой след. Сейчас сайт знает, с какой страницы мы перешли, куда мы перешли и, возможно, он знает наши действия, которые мы совершали до этого.
Также взглянем на строку с нашим запросом в анализаторе http. В графе «Получено байт» стоит большое значение, значит там что-то есть! Открываем вкладку «Получено» и что же мы там видим?
А видим мы там список нужных нам проксей. Вот она — Автоматизация с большой буквы! Мы поступили не как обыватели, избежали лишних действий. Нам нужны были прокси — они у нас есть и они в нашем http-клиенте. А как ранее я уже говорил, все действия, связанные с получением данных из http-клиента, применяются к последнему нашему запросу. Давайте вытащим их из него.
Заходим в http-клиент, выбираем действие «Содержание ответа», в действии выставляем кодировку: auto. Переменная, в которую сохранить результат: SAVED_IP. Добавляем, выполняем, смотрим.
Кто-то спросит: «Почему переменная названа SAVED_IP, а не SAVED_PROXY?». Все просто: пока что это лишь набор айпишников и портов, мы не знаем, какие из них рабочие, а какие нет. Но если вам так не удобно, вы всегда можете изменить название переменных. Главное, не оставляйте значения стандартными, дабы не путаться и не возникало пересечения переменных. Также не называйте переменные рандомными символами, а то некоторым людям порой после вас приходится сидеть и думать, что вы могли иметь ввиду.
На этом моменте наша работа с сайтом и получением прокси списка окончена. А вместе с этим и закончилась первая часть этой большой статьи.