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/

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