Web-based proxy своими руками

Веб-прокси (англ. «web-based proxy») — это прокси-сервер и анонимайзер особого вида, представляющий собой веб-приложение (чаще всего PHP или Perl скрипт) установленное на веб-сервере, выступающее в роли посредника для загрузки контента различных веб-сайтов.

Разве тяжело что-то такое сделать? Думаю, что нет. Кому читать не интересно, то сразу ссылка на GitHub kronusme/webproxy.

Условие

Необходимо реализовать веб-приложение, которое являет собой веб-прокси (как указано в определении выше) и имеет такой функционал:

  • Позволяет получить контент веб-страницы получив ее url.
  • Запрошенный url не должен присутствовать в явном виде при выполнении запросов к веб-прокси (имеется ввиду только GET).
  • В контенте требуемой страницы все ссылки должны меняться на «прокси-ссылки» (было — google.com/main.css, стало — proxy.php?url=******).
  • Тоже самое для src, href атрибутов элементов страницы.
  • В подгружаемых таблицах стилей так же необходимо проводить замены url.
  • В style так же надо заменять ссылки в @import.
  • Не принимать никаких cookies.
  • Удалить со страницы embed, object, iframe.
  • Пользователю должен быть показан реальный url страницы при просмотре ее через прокси.

Реализация

Писать будем на PHP. Для обработки DOM-дерева возьмем библиотеку simple_html_dom. Для CSS было желание использовать PHP-CSS-Parser, но пришлось отказаться, так как этот парсер обрабатывает некоторые файлы очень долго.

Надо определить компоненты, которые понадобятся:

  • Объект для обработки запросов (самый простой — отправил, получил, отделил заголовки от тела и вернул результат).
  • Объект для хранения данных об запрошенном url (будет необходимо выделить в нем хост, путь, файл и т.д).
  • Объекты, являющие собой загруженные по запросу файлы (html, css и т.д).
  • Фабрика для объектов-файлов.

С точки зрения UI будет всего два файла:

  • index.php — тут пользователь вводит необходимый ему url.
  • view.php — сюда пользователя перенаправляет после ввода url на index.php.

Из вышеописанного получилась такая диаграмма классов:

WebProxy Class Diagram

Если рассматривать код с точки зрения «кто кого когда вызывает», то получится так:

  • На view.php приходит запрос с зашифрованным url’ом.
  • url расшифровывается в page_factory (PF).
  • В PF вызывается метод get_page, который выполняет загрузку содержимого по url.
  • В зависимости от content_type ответа сервера, создается и возвращается нужный объект-страница (html, css, basic и т.д).
  • У этого объекта вызывается метод process, который выполняет различные преобразования (см. process в class.basic_page.php, class.css_page.php, class.html_page.php).
  • После этого пользователю передается заголовок с content_type объекта и обработанное тело объекта.

Тестирование

Сразу скажу, что тестирование — не мой конек. Так что обошелся самыми простенькими вещами и assertEquals 🙂 Да, тесты лежат в папке tests (уже все настроено под PhpUnit). Проверил у себя — все работает (PHP 5.3.8). Потом вспомнил, что есть сервис Travis CI (Free Hosted Continuous Integration Platform for the Open Source Community), на котором есть интеграция с GitHub’ом. Решил включить в тестирование WebProxy и развертывание на PHP 5.3, 5.4, 5.5 с помощью Travis CI (см. файл .travis.yml). Как показал запуск на Travis, WebProxy работает на всех трех проверяемых ветках PHP. Так что в Readme можно добавить небольшой пункт с красивой картинкой — Travis CI status.

Эпилог

Сейчас WebProxy пригоден для простого серфинга по статическим страничкам, но разработка не стоит на месте. В планах — корректная обработка форм, возможность приема Cookies (опционально) и т.д.

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

Ну и еще раз ссылка на GitHub kronusme/webproxy.

Продолжение — клац.

, ,

Оставить комментарий

Top ↑ | Main page | Back