ПРОЕКТЫ 


  АРХИВ 


Apache-Talk @lexa.ru 

Inet-Admins @info.east.ru 

Filmscanners @halftone.co.uk 

Security-alerts @yandex-team.ru 

nginx-ru @sysoev.ru 


  СТАТЬИ 


  ПЕРСОНАЛЬНОЕ 


  ПРОГРАММЫ 



ПИШИТЕ
ПИСЬМА












     АРХИВ :: nginx-ru
Nginx-ru mailing list archive (nginx-ru@sysoev.ru)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: allow/deny and return



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


 




Copyright © Lexa Software, 1996-2009.