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

[denis <denis@xxxxxxxxxxxxxxxx>]

26.02.2014 19:07, Maxim Dounin пишет:
> > Есть ряд проектов, которые программерам надо выставить в мир, но
> > а) проблема, что могут проиндексировать, даже несмотря на robots.txt
> Это решает любая аутентификация, будь то basic или digest.
это понятно.

> > б) это прямо запрещает лицензия битрикса, 1 лицензия - 1 место размещения.
> > Поэтому искали метод такого выставления, кроме VPN.
> Т.е. есть сайт, раздающийся по http, и чтобы раздать то же самое
> (часть того же самого) по https будет нужна дополнительная
> лицензия?
Нет, по https тоже можно отдавать. Нельзя отдавать с разных внешних 
серверов (продакшн отдельно, тестовые сервера отдельно)
в чистом виде https нам ничем не поможет, все-равно нужна авторизация.

> По моему, вас неверно информировали.  По крайней мере
> ничего подобного я там не вижу (так удивился утверждению, что
> нашёл и посмотрел).  Есть расплывчатое определение термина "сайт",
> к которому и привязаны лицензионные ограничения, но никаких
> утверждений, позволяющих сделать вывод о недопустимости https там
> не видно.  Более того, даже требования использовать только один
> домен не видно.
http://www.1c-bitrix.ru/download/manuals/ru/EULA_BUS_12.docx
4.3. Программа может быть временно установлена на дополнительный 
компьютер (ЭВМ) с целью использования исключительно для работ по 
разработке, тестированию и/или наполнению Сайта при условии отсутствия 
любого "внешнего" доступа к ней (в том числе из сети Интернет или извне 
локальной сети Пользователя). Указанная копия Программы должна быть 
немедленно удалена после завершения вышеперечисленных работ.
http://dev.1c-bitrix.ru/community/forums/forum6/topic31164/
более того, даже для разработки -- не более 1 машины.

> > а почему не будет работать вариант с разделением? например, проверяем куку
> > авторизации, если есть авторизация битриксом - просто отдаем, иначе
> > подключаем digest
> Нет ничего общего между basic-аутентификацией и куками.  Ну разве
> что кроме собственно протокола HTTP.
>
> http://en.wikipedia.org/wiki/Basic_access_authentication
ну не куки а хидеры. Если мы авторизовались через тот же curl - 
следующий запрос без спец мер снова будет как от неавторизованного.
> Судя по описанию, правильное решение вашей проблемы - вместо
> "location @apache" сделать отдельный include-файл с нужной
> конфигурацией проксирования и использовать его.
>
> Ну и откройте для себя наследование значений директив в конфигах
> nginx'а, это обычно сильно сокращает размеры конфигов.
переработаем конфиги, спасибо.

> > кстати, если локейшн описан как ^~, но выше есть другой локейшн на тот же ~
> > .jpg, все-равно в этой секции не окажемся.
> Это не так.  Если у максимально совпавшего статического location'а
> есть модификатор "^~", то регулярные выражения не проверяются.  И
> от порядка это не зависит.
location ^~ /aaa/a2/ {
действительно работает
location ^~ /aaa/a(1|2)/ {
уже нет. В таком случае непонятно, почему просто не написать location 
/aaa/a2/ и почему не срабатывает признак регэкспа.
_______________________________________________
nginx-ru mailing list
nginx-ru@xxxxxxxxx
http://mailman.nginx.org/mailman/listinfo/nginx-ru