Re: allow/deny and return

[Maxim Dounin <mdounin@xxxxxxxxxx>]

Hello!

On Wed, Oct 16, 2013 at 09:28:40PM +0300, Gena Makhomed wrote:

> 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-проверок и админка будет без защиты

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

[...]

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

Вот тут небольшая подборка плохого:

http://trac.nginx.org/nginx/ticket/97

И это не говоря о всяких мелочах вроде "try_files не работает 
из-за if'а", которые традиционно относятся к проблемам if'а, и 
развлечениях людей, которым доставляет отсутствие наследования 
try_files.

> ведь изменения там были минимальными:
> 
> location / {
>     try_files $uri $uri/ @drupal;
> }
> 
> - это просто синтаксический сахар для
> 
> location / {
>     error_page 404 = @drupal;
>     log_not_found off;
> }

Хороший пример конфига, в котором try_files - использовать, вообще  
говоря, не надо.  Хотя писать и проще.

Вариант с error_page 404 - атомарен, в то время как в варианте с 
try_files - race condition.  Между проверкой существования файла и 
его реальным открытием в модуле static для возврата клиенту - файл 
может быть удалён, и клиенту вернут 404.  Не говоря уже про лишний 
syscall.

[...]

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

Я бы делал как-то так (с точностью до проверки существования 
php-файлов на диске, дополнить при необходимости):

    location /admin/ {
        allow ...
        deny ...
        auth_basic ...

        error_page 404 = /admin/404;
        log_not_found off;

        location = /admin/404 {
            ...
        }

        location ~ \.php$ {
            fastcgi_pass ...
            ...
        }
    }

Впрочем, вариантов - масса, написать allow/deny/auth_basic никто 
не запрещает больше, чем в одном location'е.  И совершенно не 
обязательно "обходиться без использования if".

Из действительно приятных применений try_files - это проверки 
многих файлов "за раз", e.g. проверки всяких кешей с разными 
именами ($uri.htm, $uri.html, $uri.xml и т.п.), а равно проверки 
существования файла во множестве разных мест.  Писать подобные 
конструкции на error_page 404 - мучительно.

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

-- 
Maxim Dounin
http://nginx.org/en/donation.html

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