Получение меда из улья

Браузеры — это прекрасно: за многие годы они зарекомендовали себя как высоконадежный и совместимый способ предоставления потребителям расширенных цифровых возможностей. Однако иногда опыт не так «обогащен», как нам бы хотелось. К счастью, в таких случаях мы можем взломать их и удалить все хорошее, а плохое оставить позади.

Проблема

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

Может быть, это просто честный обмен, а может, и нет. Помимо этики, с академической точки зрения давайте посмотрим, как мы можем лучше всего избавиться от посредников на этом сайте и реструктурировать его, чтобы облегчить доступ к контенту. Это отличается от того, что делает типичный блокировщик рекламы, в том, что:

  1. На этом сайте есть несколько сценариев для обнаружения блокировщиков рекламы и принудительного запрета IP-адресов в случае обнаружения нарушений.
  2. Этот сайт обслуживает объявления, которые не сразу обнаруживаются с помощью общих конфигураций блокировщика рекламы, а срок действия любых пользовательских конфигураций быстро истекает из-за ротации источников.
  3. На сайте есть специальные капчи, которые мы хотели бы обойти.
  4. Поток сайтов не идеален, он требует слишком много кликов и взаимодействий, мы хотим более ленивое решение

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

Представляем Электрон

Чтобы описать это в нескольких словах для непосвященных, 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

Резюме

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

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