Re: allow/deny and return

[Maxim Dounin <mdounin@xxxxxxxxxx>]

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@xxxxxxxxx
http://mailman.nginx.org/mailman/listinfo/nginx-ru