Re: allow/deny and return

[Maxim Dounin <mdounin@xxxxxxxxxx>]

Hello!

On Wed, Oct 16, 2013 at 04:59:55PM +0300, Gena Makhomed wrote:

> On 15.10.2013 19:57, Maxim Dounin wrote:
> 
> >Все директивы модуля rewrite - это в той или иной степени выбор
> >конфигурации, даже если они unconditional.  E.g., банальный set:
> >
> >     set $file ".htpasswd";
> >     auth_basic_user_file /path/to/$file;
> >
> >так или иначе определяет конфигурацию, которая будет в дальнейшем
> >использоваться для обработки запроса.  Выполнять сначала
> >access-проверки, и только потом директивы модуля rewrite - ни разу
> >не вариант.
> 
> а если выполнять сначала только set (внутри location и внутри if)
> потом access фазу и потом уже все остальные директивы модуля rewrite?
> тогда и обратная совместимость с set не сломается и access-проверки
> сработают всегда раньше, чем "опасные" директивы return и rewrite.

Я даже и не знаю, что сказать.  Вот, например, конфиг для 
размышлений:

    set $file ".htpasswd";
    if ($true_or_false) {
        set $file ".htpasswd2";
    }

    auth_basic_user_file /path/to/$file;

Или так:

    if ($evil) {
        return 444;
    }

    set $file ".htpasswd";
    auth_basic_user_file /path/to/$file;

> кстати, если добавить директиву handler, которая работает после фазы
> try_files, то можно будет писать конфиг nginx без лишней избыточности:
> 
> location /admin {
>    satisfy any;
>    set $file ".htpasswd";
>    auth_basic_user_file /path/to/$file;
>    allow 10.1.1.1;
>    deny all;
>    handler @default;
> }

[...]

Можно добавить множество новых директив.  Но, как показывает 
практика, это не избавляет от старых проблем, а только добавляет 
новых.  Не надо умножать сущности без необходимости.

[...]

> >С якобы багом разобрались - отлично.  Возвращаемся к исходному
> >разговору - если есть идеи, как _хорошо_ объяснить пользователям,
> >почему так - you are welcome.
> 
> почему return/rewrite работает раньше access - я смог нормально понять
> только после того, как прочитал http://www.aosabook.org/en/nginx.html
> начиная со слов "Which brings us to the phases." причем, вот этой:
> 
> ...the request goes through six phases:
> 
> 1. server rewrite phase
> 2. location phase
> 3. location rewrite phase (which can bring the request back to the
> previous phase)
> 4. access control phase
> 5. try_files phase
> 6. log phase
> 
> очень важной информации нет в официальной документации.

Эта информация - подробности реализации (неправильно и не 
полностью описанные, кстати, на самом деле фаз 11).  Вываливать 
эти подробности на пользователей - плохая идея.  Человекопонятная 
и не зависящая от реализации часть этой информации - в заметных 
объемах присутсвует в документации по rewrite и во водной статье 
"Как nginx обрабатывает запросы" тут:

http://nginx.org/en/docs/http/request_processing.html

> >Аналогичный конфиг, кстати, рассматривается в подробностях тут:
> >
> >http://nginx.org/en/docs/http/ngx_http_rewrite_module.html#internals
> 
> весь остальной псевдокод после "match of regular expression" разве
> не должен быть с отступом в 4 пробела, таким же как и у "return 403" ?

Скорее нет, чем да.

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

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