Comments 14
шло второе десятилетие двадцать первого века.
+9
Я бы понял, если шаред-хостинг. Но на своем-то сервере (судя по путям) — зачем этот садомазохизм? Никто же не запрещает писать человеческие блоки Location/LocationMatch в конфигурации виртуального хоста.
0
Уважаемый автор, я думаю, что выражу общий невысказанный совет, если порекомендую вам посмотреть в сторону nginx+php-fpm.
В nginx тоже есть директива rewrite, которая (как мне кажется) гораздо-гораздо легче и прозрачнее в изучении и работе.
Они очень похожи, но по крайне мере я потратил на её изучение в nginx куда меньше времени, чем в apache.
Плюс там есть отличная директива map, недооцененность которой я в свое время постарался осветить.
В nginx тоже есть директива rewrite, которая (как мне кажется) гораздо-гораздо легче и прозрачнее в изучении и работе.
Они очень похожи, но по крайне мере я потратил на её изучение в nginx куда меньше времени, чем в apache.
Плюс там есть отличная директива map, недооцененность которой я в свое время постарался осветить.
+3
Большое спасибо! Вы, очевидно, правы на 100%.
Но у меня есть клиенты с Apache, и вопросы правки .htaccess довольно популярны. Так что приходится иногда помучиться.
Но у меня есть клиенты с Apache, и вопросы правки .htaccess довольно популярны. Так что приходится иногда помучиться.
+1
Точнее дело то не в том, что клиенты с apache, а в том, что все эти «популярные» cms заточены под apache+mod_rewrite, а у каждой cms этот файл может кардинально отличаться. Ладно, когда оно для себя, можно один раз в nginx прописать и забыть
А когда у клиентов там за месяц может затеститься десяток cms'ок, да ещё и в разных подкаталогах потом жить, тогда вообще «ховайся» — в корне битрикс, в /photo ещё какаянить cms'ина, в блоге wp и сиди, выдыхай.
А когда у клиентов там за месяц может затеститься десяток cms'ок, да ещё и в разных подкаталогах потом жить, тогда вообще «ховайся» — в корне битрикс, в /photo ещё какаянить cms'ина, в блоге wp и сиди, выдыхай.
0
Так cms'ки носят с собой свои .htaccess файлы.
0
Именно. Поэтому и приходится за nginx для вот таких вот меняющихся .htaccess'ов держать apache на шаредхостинге.
Не писать же рекурсивный чекер для .htaccess, который будет его трансформироать в конфиг nginx (
Не писать же рекурсивный чекер для .htaccess, который будет его трансформироать в конфиг nginx (
0
Да, все так делают, но я про другое.
Раз cms приходят со своими .htaccess файлами, то не надо самому их писать.
Если нужно что-то кастомное, можно добавить это в nginx.
Раз cms приходят со своими .htaccess файлами, то не надо самому их писать.
Если нужно что-то кастомное, можно добавить это в nginx.
0
Преимуществ в безопаности? Безопасности через неизвестность не бывает.
Обход 1:
engine.bbb.ru/%64ispatch.php
И в скрипте dispatch.php очень советую не забыть запретить прямой вызов самого dispatch.php.
<?php if (preg_match('#^/dispatch.php#', $_SERVER['REQUEST_URI']) == 1) { redirect_to_bad_uri(); }
Обход 1:
engine.bbb.ru/%64ispatch.php
+1
Согласен. Пример не самый удачный. Под безопасностью я имел ввиду тот факт, что скрипт dispatch.php разбирается по каждому входящему REQUEST_URI, что с ним делать и пропускает только правильные, с его точки зрения. Но я не знаю, стоит ли это уточнять в статье, ибо безопасность просто к слову пришлась, как одна из положительных характеристик упомянутого метода, и темой статьи напрямую не является.
0
Sign up to leave a comment.
Articles
Change theme settings
Отлаживаем правила RewriteRule, или немного об интимной жизни mod_rewrite