Pull to refresh

Comments 14

шло второе десятилетие двадцать первого века.
Но в избранное добавлять статью не забывают.
Похоже, мы не все знаем об этом мире.
а хорошо описано. чего б не добавить.
Я бы понял, если шаред-хостинг. Но на своем-то сервере (судя по путям) — зачем этот садомазохизм? Никто же не запрещает писать человеческие блоки Location/LocationMatch в конфигурации виртуального хоста.
Именно шаред хостинг. Указанные пути связаны с тем, что на моем домашнем компьютере установлена Ubuntu.
Уважаемый автор, я думаю, что выражу общий невысказанный совет, если порекомендую вам посмотреть в сторону nginx+php-fpm.
В nginx тоже есть директива rewrite, которая (как мне кажется) гораздо-гораздо легче и прозрачнее в изучении и работе.
Они очень похожи, но по крайне мере я потратил на её изучение в nginx куда меньше времени, чем в apache.
Плюс там есть отличная директива map, недооцененность которой я в свое время постарался осветить.
Большое спасибо! Вы, очевидно, правы на 100%.

Но у меня есть клиенты с Apache, и вопросы правки .htaccess довольно популярны. Так что приходится иногда помучиться.
Точнее дело то не в том, что клиенты с apache, а в том, что все эти «популярные» cms заточены под apache+mod_rewrite, а у каждой cms этот файл может кардинально отличаться. Ладно, когда оно для себя, можно один раз в nginx прописать и забыть
А когда у клиентов там за месяц может затеститься десяток cms'ок, да ещё и в разных подкаталогах потом жить, тогда вообще «ховайся» — в корне битрикс, в /photo ещё какаянить cms'ина, в блоге wp и сиди, выдыхай.
Так cms'ки носят с собой свои .htaccess файлы.
Именно. Поэтому и приходится за nginx для вот таких вот меняющихся .htaccess'ов держать apache на шаредхостинге.
Не писать же рекурсивный чекер для .htaccess, который будет его трансформироать в конфиг nginx (
Да, все так делают, но я про другое.
Раз cms приходят со своими .htaccess файлами, то не надо самому их писать.
Если нужно что-то кастомное, можно добавить это в nginx.
Если у меня одна конкретная cms — или конечное контролируеме мною их количество внутри компании/проетов — я так и сделаю.
Но не в условиях когда у меня несколько тысяч доменов на один сервер шаредхостинга.
Преимуществ в безопаности? Безопасности через неизвестность не бывает.
И в скрипте dispatch.php очень советую не забыть запретить прямой вызов самого dispatch.php.
<?php

if (preg_match('#^/dispatch.php#', $_SERVER['REQUEST_URI']) == 1) {
    redirect_to_bad_uri();
}


Обход 1:
engine.bbb.ru/%64ispatch.php
Согласен. Пример не самый удачный. Под безопасностью я имел ввиду тот факт, что скрипт dispatch.php разбирается по каждому входящему REQUEST_URI, что с ним делать и пропускает только правильные, с его точки зрения. Но я не знаю, стоит ли это уточнять в статье, ибо безопасность просто к слову пришлась, как одна из положительных характеристик упомянутого метода, и темой статьи напрямую не является.
Sign up to leave a comment.

Articles

Change theme settings