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
