allow/deny and return

[Gena Makhomed]

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.

кстати, если добавить директиву 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;
}

location / {
    handler @default;
}

location /for-test/ {
    if ($arg_test=123) {
         handler @special; # проблем не должно быть
    }
    handler @default;
}

location @default {
   root ...;
   try_files $uri $uri/ =404;
   location ~ \.php$ {
       root ...;
       try_files $uri @virtual;
       fastcgi_pass ...;
       fastcgi_param SCRIPT_FILENAME /path/to$fastcgi_script_name;
       fastcgi_param SCRIPT_NAME     $fastcgi_script_name;
       fastcgi_param QUERY_STRING    $args;
   }
}

location @virtual {
   fastcgi_pass ...;
   fastcgi_param SCRIPT_FILENAME /path/to/index.php;
   fastcgi_param SCRIPT_NAME     /index.php;
   fastcgi_param QUERY_STRING    q=$uri&$args;
}

>>>> по крайней мере, в UNIX и даже в WINDOWS все работает именно так:
>>>> если доступа к файлу нет, никаких операций с ним сделать нельзя.
>>
>>> В Антоном конфиге нет файла.  Есть инструкция "при выборе
>>> конфигурации для обработки запросов вернуть ответ с кодом 200".
>>
>> файла нет. но есть location /closed и есть директивы задания доступа
>> кому allow, а кому deny. то что return срабатывает раньше deny - это
>> будет совершенно неожиданно для более чем 99% пользователей nginx...
>
> С якобы багом разобрались - отлично.  Возвращаемся к исходному
> разговору - если есть идеи, как _хорошо_ объяснить пользователям,
> почему так - 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

очень важной информации нет в официальной документации.

кстати, если пользователи столкнутся с ситуацией, что access-обработчики
не работают в location где используется return и rewrite -
они в первую очередь буду искать причину в документации
к соответствующим access модулям, а не в модуле rewrite

> Аналогичный конфиг, кстати, рассматривается в подробностях тут:
>
> http://nginx.org/en/docs/http/ngx_http_rewrite_module.html#internals

весь остальной псевдокод после "match of regular expression" разве
не должен быть с отступом в 4 пробела, таким же как и у "return 403" ?

-- 
Best regards,
  Gena