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@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru