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

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