ПРОЕКТЫ 


  АРХИВ 


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 17.10.2013 17:09, Maxim Dounin wrote:

тогда "allow/deny vs return" перестанет быть такой уж острой проблемой.
сейчас код "error_page 456 @default; return 456;" использовать нельзя,
потому что он отрабатывает до access-проверок и админка будет без защиты

Повторяю: не перестанет.  Если есть проблема - нужно её решать, а
не придумывать альтернативы.  Потому что так или иначе _будут_
люди, которые пишут return, rewrite, и т.п. неправильно.  И от
добавления нового механизма - их не станет меньше.  Лучшее, на что
приходится расчитывать, это что их станет меньше в процентах от
общего числа пользователей - но и это не гарантировано.  Наоборот,
есть неслабая вероятность, что их станет больше, потому что
пользователи окончательно запутаются в существующих механизмах.

Понятно. А как решать-то? "Выполнять сначала access-проверки,
и только потом директивы модуля rewrite - ни разу не вариант"

Как уже и предлагалось - методом правильного документирования того
факта, что директивы модуля rewrite - это часть процесса выбора
конфигурации.  И всяческие директивы allow/deny/whatever -
применяются уже после того, как оный выбор случился.

а что делать, если необходимо, чтобы директивы модуля
rewrite отработали после проверок allow/deny/whatever?

например, если после прохождения всех access-проверок
надо сделать еще и проверку на существование php файла:

     if (!-f $request_filename) {
         return 404;
     }

и разная реакция в зависимости от того, есть этот файл на диске или нет,
- но только для тех клиентов, которым доступ в этот location разрешен.

и в том и в другом случае запрос уходит на backend, только uri разный.
если доступ не разрешен - тогда ответ 403 и на backend ничего не идет.

если файл с расширением .php существует, запрос уходит такой:

  fastcgi_pass ...;
  fastcgi_param SCRIPT_FILENAME /path/to/admin$fastcgi_script_name;
  fastcgi_param SCRIPT_NAME     $fastcgi_script_name;
  fastcgi_param QUERY_STRING    $args;

если файл с расширением .php не существует, запрос уходит такой:

  fastcgi_pass ...;
  fastcgi_param SCRIPT_FILENAME /path/to/admin/index.php;
  fastcgi_param SCRIPT_NAME     /admin/index.php;
  fastcgi_param QUERY_STRING    q=$uri&$args;

подозреваю, что даже после документирования без try_files не получится.
потому что это все внутри location /admin/ { ... } с access-проверками.

И такая конструкция - не отличается от try_files практически
ничем.  Наоборот, в отличии от try_files она работает, если вдруг
в этом location'е случится alias.

директива try_files нормально работает после access-проверок. так что
"Не надо умножать сущности без необходимости" - необходиость тут есть?

Речь, впрочем, не об этом.  Речь о том, что try_files, который
делался как попытка "решить" проблемы if'а, вытеснив его из
конфигов, ни разу его не вытеснил.  Наоборот, к существовавшим
ранее проблемам - добавились новые, в том числе - связанные с
работой try_files со всё тем же if'ом.

а разве есть лучший вариант решения проблем с if ?
"ничего не делать" - этот вариант хуже чем try_files

и try_files и handler уменьшают количество случаев,
когда необходимо использовать "опасные" варианты if.

Повторяю: добавление try_files не решило проблем с if'ом.  В
результате как раз с проблемами if'а - ничего не было сделано, а
вместо этого усилия были потрачены на try_files и борьбу с его
проблемами.  Если бы вместо добавления try_files соответствующие
усилия были потрачены именно на _решение_ проблем - было бы лучше.

никто и не обещал, что try_files решит все проблемы с if.

но многие случаи написания конфигурации try_files упрощает.

причем это вне зависимости от того, есть у if проблемы или их нет.

и во многих случаях можно обойтись try_files без использования if.

И это общая проблема всех подобных попыток "уменьшить количество
случаев" вместо реального решения проблемы.  Решать проблему всё
равно рано или поздно придётся, и откладывание этого решения -
лишь ухудшает ситуацию.

что в таком случае можно считать рельным решением проблем директивы if,
- чтобы не осталось ни одного глюка из http://wiki.nginx.org/IfIsEvil ?

про проблемы директивы if говорится очень давно, но видимо эти проблемы
нетривиальные, раз до сих пор никому так и не удалось их реально решить

P.S. There are only two kinds of languages: the ones
     people complain about and the ones nobody uses.
                                 - Bjarne Stroustrup

--
Best regards,
 Gena

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


 




Copyright © Lexa Software, 1996-2009.