Re: allow/deny and return

[Gena Makhomed <gmm@xxxxxxxxx>]

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