Некоторое предисловие
Простая задача по поддержанию блога на собственном хостинге подчас перестает быть такой простой, как казалось на первый взгляд. Так, приходится выбирать между функционалом и безопасностью, между быстродействием и оформлением. Так, начав свой путь в поддержании блога на WordPress-движке с 50 плагинов-расширений, я перешел на 5 самых необходимых, без которых трудно обойтись, дописав весь нужный функционал в сам код темы. Так, с использования тем со встроенными фичами я пришел к созданию child-тем, добавляя каждую новую функцию и элементы оформления только по необходимости. Слишком много лазеек оставляют расширения, слишком много ресурсов забирают дополнения. Поэтому, если делать блог самому — это труд. Не тяжелый, и тут не надо иметь семь пядей во лбу. Но он должен быть вдумчивый, последовательный и кропотливый.
И вот, вроде бы, когда у тебя уже полностью собранный под тебя продукт, который тебя устраивает на 120%, появляется какая-нибудь информация о том, что у тебя что-то не работает и хотелось бы, чтобы всё-таки работало. Эти вещи каждый раз разные по объему, по трудности, и они никогда не повторяются даже близко.
И вот, после непродолжительного счастливого владения своим продуктом, вдруг появились они — вездесущие сканеры уязвимостей, тотальная регистрация ботов в системе, попытки захватить контроль над админкой, используя слабые места файловой системы хостера… В общем, в какой-то момент эта борьба с ветряными мельницами начинает надоедать. И вместо ежедневного добавления в access deny подсетей бот-ферм, ты хочешь найти кое-что более простое и в то же время лучшее. Хорошо, что сейчас куча инструментов против бот-ферм. И, конечно, первое, что приходит в голову — защита от сетевых атак вроде CloudFlare. У моего хостера подобный инструмент есть. Подключаем. Думаем, что всё под контролем, но… всегда есть это но.
Вновь включенная защита от сетевых атак действует по принципу проверки клиента-посетителя на вшивость и проверки на всё и вся. Сначала клиент загружает незаметно быстро JavaScript, который, если всё хорошо, потом уже говорит браузеру, где взять нормальный контент. Это же хорошо? Да! Когда оно там как-то работает без тебя, не мешает тебе и твоим читателям. А когда оно начинает мешать? Отключать? А бот-фермы? Не отключать? А читатели?
В общем, этот метод проверки приложил rss-feed этого блога. Потому что на первый же запрос он любому rss-клиенту (да и валидатору) отвечал HTML/Text, на что тот обижался.
Как-то отдельно страницы выключить из работы защитника мне не удалось, поэтому пришлось поискать нестандартное решение. И оно нашлось. Необходимо просто-напросто выкладывать rss-ленту на другом домене.
Проблема с RSS: как её решить
Пример именно моей проблемы
Я столкнулся с этой проблемой на сайте. Стандартный фид WordPress по адресу https://brmx.ru/feed/ отдавал внешним валидаторам HTML-страницу с JavaScript-проверкой и cookie. Браузер проходил эту проверку, а валидаторы и клиенты rss не могли выполнить JavaScript, поэтому видели обычную веб-страницу.
Решение
Код в данном случае я публиковать пока не буду, потому что там есть технически уязвимые моменты, при раскрытии которых данный блог можно приложить. Поэтому пока теория, а для практики найдем какое-нибудь другое время.
Для решения проблемы был создан отдельный субдомен https://rss.brmx.ru и на нем опубликован PHP-скрипт по адресу /rss.php, который формирует RSS напрямую через WordPress, в обход нашей системы защиты.
Логика проделанного
- Создаем отдельный субдомен rss.anyrandomdomain.ru для самостоятельной выдачи RSS без проблемной защиты основного сайта.
- На субдомене размещаем PHP-скрипт, который подключает WordPress через wp-load.php, получает опубликованные записи и формирует RSS 2.0 (тут важно, чтобы скрипт работал в том же файловой системе на стороне сервера, и имел к папке установки wordpress необходимый доступ).
- В процессе настраиваем путь к WordPress и следим чтобы версия PHP на субдомене была такой же, как и на основном домене.
- Скрипт именуем как угодно (у меня — это rss.php) только не index.php, чтобы избежать обработки адреса как главной страницы основного сайта.
Резюме
Рабочий адрес RSS у моего сайта теперь такой: https://rss.brmx.ru/rss.php (ссылка на фид в самом низу каждой страницы этого сайта).
И хотя сейчас всё меньше людей пользуются RSS, а в стандартных рекомендациях в плагинах по безопасности WordPress даже есть указания по отключению rss-фида, всё же надеюсь на то, что этот пост поможет вам решить проблему с RSS на вашем сайте.