Привет всем! В связи с ростом блокировок, в том числе необоснованных, сайтов со стороны государства, вашему вниманию предлагается описание идеи, а также прототип настроек сайта, защищенного от блокировок по конкретному пути и доменному имени. Идеи по защите от блокировок: будут изложены в других постах. Кому интересна тема, заходите под кат. https://github.com/http-abs/http-abs/ Принцип защиты заключается в том, что каждый пользователь получает уникальную пару из индивидуального (под)домена и префикса пути для просмотра сайта. Назовем эту пару идентификатором агента. Если по каким-то причинам, вы можете управлять только ограниченным набором поддоменов, пользователь будет конечно, разделять свой поддомен с некоторыми другими пользователями. Конечно, в случае ограничения, указанного выше, жизнь станет сложнее у тех пользователей, которым не повезло разделить поддомен с оператором блокировок. Но не сильно. При условии предыдущего примечания. Легко. Идентификатор агента, выделенный пользователю для просмотра сайта, сохраняется у него в куках. Пользователь просто делится ссылкой из адресной строки. Чтобы изолировать оператора блокировок. Если повезет, после нескольких блокировок, его можно будет даже идентифицировать. Ничуть, от него не требуется в буквальном смысле ничего. Он заходит на сайт обычным образом, читает материалы и делится ссылками. В его жизни меняется только вид адресной строки. Возможно. Ему не придется учитывать префикс пути и поддомен, входящие в идентификатор агента: их будет обрезать обработчик на первой стадии обработки входящего URL. Однако, чтобы сделать процесс совершенно прозрачным, возможно придется еще потрудиться. Конечно. Но ему будет гораздо труднее доказывать необходимость блокировки бесконечного количества ссылок на материал, сформированных по замысловатому правилу, при том, что правила могут и измениться на еще более замысловатые. Такое развитие событий не исключено, но эти случаи я хочу рассмотреть отдельно в другой статье. Возможно, мы с вами вместе придумаем что-то дополнительно в комментариях. Для того, чтобы сделать процесс максимально прозрачным, код сосредоточен в сервере фронтенда nginx. Это позволяет ставить под защиту самые разнообразные прикладные серверы практически без ограничений. Поскольку обработка запроса будет весьма нетривиальной, использован дополнительный пакет libnginx-mod-http-lua, внедряющий язык lua в процесс обработки запросов под nginx. В идеале, обработка должна производиться так, чтобы бакенд (аплинк, прикладной сервер) — вовсе не был озабочен тем, поставили ли его под защиту. Ему приходят запросы по URL, из которого убраны все элементы идентификатора агента (назовем такие чистыми URL). Чтобы не переделывать возвращаемые страницы, переход по чистому URL с установленной кукой идентификатора агента, вызывает редирект на индивидуальный URL. Фронтенд не хранит состояние нигде, кроме куки идентификатора агента. На браузере не задействовано ни одной строки кода javascript. Используется только протокол HTTP. Фактически, реализован лишь proof-of-concept, позволяющий наблюдать реальную работу алгоритма. Не решено множество деталей, связанных с упаковкой продукта: модульность, выделение и проверка параметров и так далее. Для поддоменов, выбрана схема с фиксированным набором поддоменов, пригодная для использования в паре с файлом hosts, без инсталляции дополнительного сервера DNS. Формат префикса пути предопределен и представляет из себя 32 цифры по основанию 16. Параметры запуска установлены пока прямо в коде. Набор поддоменов (a, b, c) установлен в переменной и может быть расширен. Домен установлен, как example.com. Бакенд ожидается на точке http://127.0.0.1:8000 Растущая угроза внезапных блокировок заставляет готовиться заранее и изобретать методы защиты от них владельцев даже вполне лояльных сайтов. Такая защита вполне возможна, не требует никаких телодвижений со стороны пользователя и может быть реализована вполне скромным объемом усилий со стороны администратора сайта.