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

[Maxim Dounin]

Hello!

On Wed, Feb 26, 2014 at 06:42:41PM +0400, denis wrote:

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

Это решает любая аутентификация, будь то basic или digest.

> б) это прямо запрещает лицензия битрикса, 1 лицензия - 1 место размещения.
> Поэтому искали метод такого выставления, кроме VPN.

Т.е. есть сайт, раздающийся по http, и чтобы раздать то же самое 
(часть того же самого) по https будет нужна дополнительная 
лицензия?

По моему, вас неверно информировали.  По крайней мере 
ничего подобного я там не вижу (так удивился утверждению, что 
нашёл и посмотрел).  Есть расплывчатое определение термина "сайт", 
к которому и привязаны лицензионные ограничения, но никаких 
утверждений, позволяющих сделать вывод о недопустимости https там 
не видно.  Более того, даже требования использовать только один 
домен не видно.

> а почему не будет работать вариант с разделением? например, проверяем куку
> авторизации, если есть авторизация битриксом - просто отдаем, иначе
> подключаем digest

Нет ничего общего между basic-аутентификацией и куками.  Ну разве 
что кроме собственно протокола HTTP.

http://en.wikipedia.org/wiki/Basic_access_authentication

> и попутно маленький вопрос: как можно принудительно переслать в именованный
> 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 месяц, конфигов много и они сильно разные.

Судя по описанию, правильное решение вашей проблемы - вместо 
"location @apache" сделать отдельный include-файл с нужной 
конфигурацией проксирования и использовать его.

Ну и откройте для себя наследование значений директив в конфигах 
nginx'а, это обычно сильно сокращает размеры конфигов.

> кстати, если локейшн описан как ^~, но выше есть другой локейшн на тот же ~
> .jpg, все-равно в этой секции не окажемся.

Это не так.  Если у максимально совпавшего статического location'а 
есть модификатор "^~", то регулярные выражения не проверяются.  И 
от порядка это не зависит.

Подробнее тут:

http://nginx.org/r/location

-- 
Maxim Dounin
http://nginx.org/