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