Re: allow/deny and return

[Gena Makhomed <gmm@xxxxxxxxx>]

On 16.10.2013 20:33, Maxim Dounin wrote:

> > > > кстати, если добавить директиву 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;
> > > > }
> > > Можно добавить множество новых директив.  Но, как показывает
> > > практика, это не избавляет от старых проблем, а только добавляет
> > > новых.  Не надо умножать сущности без необходимости.
> > а какие новые проблемы добавятся в этом случае?
> Понятия не имею - подобные вещи выясняются в основном в процессе,
> кроме уж совсем очевидных глупостей.  Я как бы пытаюсь сказать,
> что на обсуждаемый вопрос с allow/deny vs return это добавление
> никак не повлияет.
тогда "allow/deny vs return" перестанет быть такой уж острой проблемой.
сейчас код "error_page 456 @default; return 456;" использовать нельзя,
потому что он отрабатывает до access-проверок и админка будет без защиты

include использовать тоже не имеет смысла и остается только copy/paste.

ладно, если это разные по смыслу фрагменты исходника, тогда дублирование
и избыточность еще можно оправдать "квадратно-гнездовым методом",
а если это полностью идентичный handler, который просто присутствует
в разных местах сайта, например, для админки и остальной части сайта?

include - это не решение, когда разных сайтов несколько десятков/сотен.

проблема с дублированием идентичных фрагментов конфига уже неоднократно
обсуждалась ранее, например: http://www.lexa.ru/nginx-ru/msg26393.html
но удобного и эффективного решения ранее придумано еще не было...

> Игорь тут уже как-то попробовал решать проблемы модуля rewrite с
> помощью добавления директивы try_files.  Стало только хуже, т.к.
> старые проблемы никуда не делись, а новых добавилось - в
> количестве.
а какие проблемы появились из-за добавления директивы try_files ?

ведь изменения там были минимальными:

location / {
    try_files $uri $uri/ @drupal;
}

- это просто синтаксический сахар для

location / {
    error_page 404 = @drupal;
    log_not_found off;
}

плюс добавилась одна фаза, которая работает перед content handler`ами.

вообще-то это достаточно удобно и часто надо: существующие на диске
файлы обрабатывать одним способом, а запросы, которые не соответствуют
существующим на диске файлам - другим способом. try_files тут помогает
обойтись без использования if из модуля rewrite: if ( -f $uri ) {...},
который отрабатывает до access-проверок и служит для выбора location.

допустим, нет у нас директивы try_files. каким образом тогда можно
сделать с помощью nginx защищенную basic auth и allow/deny админку,
в которой статика будет отправляться клиентам напрямую, существующие
на диске файлы с расширением .php будут обрабатываться другим способом,
а запросы которым не соответствует файл на диске - третьим способом ?

было бы очень интересно посмотреть на вариант решения без try_files.

--
Best regards,
 Gena

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