Re: auth_digest -- несколько вопросов

[denis <denis@xxxxxxxxxxxxxxxx>]

26.02.2014 18:14, Maxim Dounin пишет:
> Единственный вариант, который _теоретически_ может работать - это
> использование нескольких альтернативных схем аутентификации.
> Клиенту отправляется несколько разных WWW-Authenticate заголовков,
> с разными схемами аутентификации, а он выбирает из них ту, которая
> ему больше нравится.  На практике - и так тоже будут проблемы.
> То, что вы описываете - работать не будет гарантированно.
>
> BTW, а с какой целью используется digest-аутентификация?
> Безотносительно конкретного модуля - проблем она, IMHO, создаёт
> больше, чем решает.  Обычно проще и правильнее использовать basic
> вкупе с ssl.
Есть ряд проектов, которые программерам надо выставить в мир, но
а) проблема, что могут проиндексировать, даже несмотря на robots.txt
б) это прямо запрещает лицензия битрикса, 1 лицензия - 1 место размещения.
Поэтому искали метод такого выставления, кроме VPN.

а почему не будет работать вариант с разделением? например, проверяем 
куку авторизации, если есть авторизация битриксом - просто отдаем, иначе 
подключаем digest
и попутно маленький вопрос: как можно принудительно переслать в 
именованный location? что-то типа try_files @apache
например, если надо описать ряд локейшенов, но не через регэкспы, чтобы 
приоритет не имел значения. например
location @apache {
proxy_pass .....
}

location = /a1/ {
try_files @apache;
}
location /a2/ {
try_files @apache;
}

таких секций может быть с десяток. Если объединить в 1 локейшн вида ~ 
/a(1|2)/ - то если выше будет прописан показ картинок (~ .(jpg|png)), то 
в эти секции запрос уже не попадает.
Нужно это, чтобы вынести их в отдельный конфиг и инклудить в куче 
проектов, но не заботиться о порядке блоков. Без инклудов не вариант, 
править 50+ конфигов руками хотя бы раз в неделю - извините, нам такого 
не надо. Писать систему шаблонов, после каждого изменения заново 
пересоздавать все файлы-конфиги -- работы не на 1 месяц, конфигов много 
и они сильно разные.
кстати, если локейшн описан как ^~, но выше есть другой локейшн на тот 
же ~ .jpg, все-равно в этой секции не окажемся.
_______________________________________________
nginx-ru mailing list
nginx-ru@xxxxxxxxx
http://mailman.nginx.org/mailman/listinfo/nginx-ru