allow/deny and return

[Gena Makhomed]

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