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