Получение меда из улья
Браузеры — это прекрасно: за многие годы они зарекомендовали себя как высоконадежный и совместимый способ предоставления потребителям расширенных цифровых возможностей. Однако иногда опыт не так «обогащен», как нам бы хотелось. К счастью, в таких случаях мы можем взломать их и удалить все хорошее, а плохое оставить позади.
Проблема
Представьте себе: вы нашли веб-сайт, на котором есть нужный вам контент, но оказалось, что на нем полно рекламы. Это не очень хорошая реклама, с этим все в порядке, это ужасная реклама, которая удерживает вас от загрузки вредоносного ПО одним щелчком мыши.
Может быть, это просто честный обмен, а может, и нет. Помимо этики, с академической точки зрения давайте посмотрим, как мы можем лучше всего избавиться от посредников на этом сайте и реструктурировать его, чтобы облегчить доступ к контенту. Это отличается от того, что делает типичный блокировщик рекламы, в том, что:
- На этом сайте есть несколько сценариев для обнаружения блокировщиков рекламы и принудительного запрета IP-адресов в случае обнаружения нарушений.
- Этот сайт обслуживает объявления, которые не сразу обнаруживаются с помощью общих конфигураций блокировщика рекламы, а срок действия любых пользовательских конфигураций быстро истекает из-за ротации источников.
- На сайте есть специальные капчи, которые мы хотели бы обойти.
- Поток сайтов не идеален, он требует слишком много кликов и взаимодействий, мы хотим более ленивое решение
Обратите внимание, что я не могу предоставить здесь какой-либо конкретный исходный код, который подорвет мой целевой сайт. Однако я опубликую общий код, который описывает важные аспекты решения.
Представляем Электрон
Чтобы описать это в нескольких словах для непосвященных, Electron — это настраиваемый браузер хрома с сантехникой Node JS.
В то время как большинство браузеров ориентированы на песочницу и контроль ресурсов для предотвращения вредоносных векторов и ограничения воздействия системы, Electron создан с учетом глубокой системной интеграции.
Ограничения браузера, такие как CORS, ограничения жестов, инициируемые пользователем, и невозможность ссылаться на файловую систему в режиме, отличном от песочницы, больше не связывают разработчиков в средах Electron. Кроме того, благодаря доступу к среде выполнения NodeJS разработчики могут использовать код C и системные API для написания некоторых довольно сложных и глубоко интегрированных опытов.
Самое главное, при этом сохраняются преимущества взаимозаменяемого пользовательского интерфейса, написанного на HTML, и совместимость с NodeJS и Chromium. На самом деле код моего приложения легко запускается в Mac OS, Windows и Linux с незначительными усилиями.
Самое приятное то, что вы, скорее всего, уже использовали электронные приложения! Вы можете просмотреть более полный список здесь, но на ум приходят VS Code, Atom, Skype и Slack.
Кстати, существует ложное представление о том, что электронные приложения так же безопасны, как и их эквиваленты на веб-сайтах. Имейте в виду, что, хотя сам электрон безопасен, разработчики имеют те же привилегии, что и стандартный исполняемый файл для хост-платформы.
Понимание архитектуры высокого уровня
Наше приложение будет состоять из нескольких окон, которыми централизованно управляет фоновый процесс, содержащий ссылки на них (давайте назовем его «основной процесс»).
- Каждое окно будет иметь свой собственный процесс рендеринга, отделенный от основного процесса.
- Все окна будут взаимодействовать с основным процессом, используя IPC через общие обработчики, которые мы создаем.
- Windows не будет знать друг о друге: связь между окнами будет осуществляться через основной процесс
На схеме это выглядит следующим образом:
- Окно 1: основное окно, с которым взаимодействует пользователь. Постоянно доступен для управления функциями приложения и является «экраном перехода» для пользователя.
- Окно 2: Окно парсера с временным созданием экземпляров, преимущественно используемое для подделки начальных сеансов против SDK безопасности, которые выполняются в браузере.
- Окно 3: всплывающее окно, используемое для отображения контекстного контента.
Начиная
Я предполагаю, что у нас уже установлена обновленная версия Node. Давайте начнем с проекта vanilla node:
mkdir my_electron_project cd my_electron_project npm init # Use whichever parameters suit you best # Install electron as a developer dependency npm install electron --save-dev # Create a source folder mkdir src src/site src/lib touch src/index.js src/site/app.html src/site/app.js
В результате получается следующая структура проекта:
my_electron_project ├── node_modules ├── package.json ├── package-lock.json └── src ├── index.js ├── lib └── site ├── app.html └── app.js
В приведенной выше схеме проекта:
- Весь написанный нами код помещается в src. Позже мы будем использовать папку dist для размещения наших скомпилированных файлов в
- Папка сайта — это место, где мы будем размещать наши ресурсы рендеринга, такие как CSS, HTML и вспомогательные файлы JS.
- Папка lib — это место, где мы будем размещать наши вспомогательные библиотеки node.js.
index.js
Index.js будет точкой входа для нашего приложения, мы будем использовать его для создания экземпляра электрона и поддержания его состояния. Мы также позволим ему организовать действия по инициализации нашего приложения.
На высоком уровне в данном случае он будет отвечать за:
- Инициализация нашего основного рендера с загрузочным экраном
- Инициализация целевого веб-сайта и обеспечение возможности извлечения файлов cookie облачных факелов, которые затем сохраняются в приложении.
- Предоставление нашему приложению универсального обработчика IPC для управления связью между службами рендеринга и узла.
app.js
Содержит нашу основную логику рендеринга интерфейса. То, что вы здесь укажете, будет зависеть от вашего варианта использования, но есть два важных компонента, которые я хочу обсудить:
- Обработчик IPC: мы создадим еще один обработчик IPC для отправки инструкций нашему основному процессу. Он отправит точную библиотеку, метод, аргументы и даже свой собственный путь обратного вызова основному процессу. Он будет полностью отвечать за свою собственную оркестровку вызовов и управлять библиотеками основных процессов в соответствии со своими контекстными требованиями.
- Общий одноэлементный обратный вызов: будет учитывать ответы основного процесса, когда он выполнит свои инструкции по задаче, и примет соответствующие меры.
окно.js
Этот файл упоминается в index.js и говорит сам за себя. Он просто отслеживает окна и предоставляет обертку над экземпляром электрона по умолчанию, чтобы стандартизировать наш подход к обработке меню и т. д.
запросы.js
Этот файл довольно ванильный, поэтому я не буду публиковать его здесь. На высоком уровне он использует комбинацию Cheerio и Request для извлечения контента с нашего целевого веб-сайта и его обработки в интерпретируемом формате для рендеринга.
Cheerio здесь более эффективен, чем JQuery при рендеринге, поскольку он не создает DOM. Запрос дает нам полную гибкость запросов Node JS и асинхронную обработку вместо ограниченных возможностей браузера. Хотя теперь вы можете вызывать библиотеки Node.JS из рендеринга, это может стать концептуально беспорядочным и загромождать ваш интерфейс.
Несколько полезных фишек
- Вы можете создать экземпляр своего приложения, используя эту команду из терминала (убедитесь, что вы не используете терминал, основанный на электронах, поскольку это вызовет проблемы):
./node_modules/electron/dist/electron src/
- Вы можете опубликовать свое приложение, используя что-то вроде электронного издателя.
# From your project CWD npm install electron-publisher -g npm install electron-prebuilt-compile --save-dev mkdir dist #Build windows and linux binaries electron-packager . generic-app --overwrite --platform=linux --platform=win32 --arch=x64 --prune=true --out=dist --asar=true
Резюме
Используя приведенные выше концепции, вы можете начать работу с отказа от посредников на своем первом веб-сайте в академических целях.
Конечно, большинство сайтов могут добавлять дополнительные уровни сложности в виде капчи, однако большинство капч можно решить, импортировав пару библиотек. Там, где капча является пользовательской, вы реализуете решение с источником пользователя, в котором успешные ответы могут быть переданы на сервер, а затем распространены среди других пользователей.