Hello!

On Thu, Oct 17, 2013 at 03:55:17PM +0300, Gena Makhomed wrote:

> On 17.10.2013 2:18, Maxim Dounin wrote:
>
> >>тогда "allow/deny vs return" перестанет быть такой уж острой проблемой.
> >>сейчас код "error_page 456 @default; return 456;" использовать нельзя,
> >>потому что он отрабатывает до access-проверок и админка будет без защиты
> >
> >Повторяю: не перестанет. Если есть проблема - нужно её решать, а
> >не придумывать альтернативы. Потому что так или иначе _будут_
> >люди, которые пишут return, rewrite, и т.п. неправильно. И от
> >добавления нового механизма - их не станет меньше. Лучшее, на что
> >приходится расчитывать, это что их станет меньше в процентах от
> >общего числа пользователей - но и это не гарантировано. Наоборот,
> >есть неслабая вероятность, что их станет больше, потому что
> >пользователи окончательно запутаются в существующих механизмах.
>
> Понятно. А как решать-то? "Выполнять сначала access-проверки,
> и только потом директивы модуля rewrite - ни разу не вариант"

Как уже и предлагалось - методом правильного документирования того
факта, что директивы модуля rewrite - это часть процесса выбора
конфигурации. И всяческие директивы allow/deny/whatever -
применяются уже после того, как оный выбор случился.

[...]

> location ~ \.php$ {
> if (-e $uri) {
> fastcgi_pass ...
> ...
> }
> fastcgi_pass ...
> ...
> }
>
> так? но этот способ ведь не рекомендуется, потому что IfIsEvil.

Нет,

if (!-f $request_filename) {
return 404;
}

И такая конструкция - не отличается от try_files практически
ничем. Наоборот, в отличии от try_files она работает, если вдруг
в этом location'е случится alias.

[...]

> >Речь, впрочем, не об этом. Речь о том, что try_files, который
> >делался как попытка "решить" проблемы if'а, вытеснив его из
> >конфигов, ни разу его не вытеснил. Наоборот, к существовавшим
> >ранее проблемам - добавились новые, в том числе - связанные с
> >работой try_files со всё тем же if'ом.
>
> а разве есть лучший вариант решения проблем с if ?
> "ничего не делать" - этот вариант хуже чем try_files
>
> и try_files и handler уменьшают количество случаев,
> когда необходимо использовать "опасные" варианты if.

Повторяю: добавление try_files не решило проблем с if'ом. В
результате как раз с проблемами if'а - ничего не было сделано, а
вместо этого усилия были потрачены на try_files и борьбу с его
проблемами. Если бы вместо добавления try_files соответствующие
усилия были потрачены именно на _решение_ проблем - было бы лучше.

И это общая проблема всех подобных попыток "уменьшить количество
случаев" вместо реального решения проблемы. Решать проблему всё
равно рано или поздно придётся, и откладывание этого решения -
лишь ухудшает ситуацию.

--
Maxim Dounin
http://nginx.org/en/donation.html

_______________________________________________
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru