Hello! On Wed, Feb 26, 2014 at 07:29:50PM +0400, denis wrote:
> 26.02.2014 19:07, Maxim Dounin пишет: > >>Есть ряд проектов, которые программерам надо выставить в мир, но > >>а) проблема, что могут проиндексировать, даже несмотря на robots.txt > >Это решает любая аутентификация, будь то basic или digest. > это понятно. > > >>б) это прямо запрещает лицензия битрикса, 1 лицензия - 1 место размещения. > >>Поэтому искали метод такого выставления, кроме VPN. > >Т.е. есть сайт, раздающийся по http, и чтобы раздать то же самое > >(часть того же самого) по https будет нужна дополнительная > >лицензия? > Нет, по https тоже можно отдавать. Нельзя отдавать с разных внешних серверов > (продакшн отдельно, тестовые сервера отдельно) > в чистом виде https нам ничем не поможет, все-равно нужна авторизация. Ну так и в чём тогда проблема использовать basic + ssl, как и предлагалось ранее? Исходный вопрос, на который хотелось получить ответ, - зачем вам digest, да ещё и в виде стороннего модуля, когда есть способ проще и лучше. Впрочем, можно считать, что ответ я получил - какой-либо осмысленной причины нет. Спасибо. [...] > >>а почему не будет работать вариант с разделением? например, проверяем куку > >>авторизации, если есть авторизация битриксом - просто отдаем, иначе > >>подключаем digest > >Нет ничего общего между basic-аутентификацией и куками. Ну разве > >что кроме собственно протокола HTTP. > > > >http://en.wikipedia.org/wiki/Basic_access_authentication > ну не куки а хидеры. Если мы авторизовались через тот же curl - следующий > запрос без спец мер снова будет как от неавторизованного. В подобной схеме ничто не помешает пользователю прислать заголовок Authorization с якобы данными для бекенда, а на самом деле запрос сделать туда, где никакие пароли бекенд не проверяет - тем самым сделав аутентификацию на уровне nginx'а бессмысленной. Вариант, который будет работать - это явно разделить (e.g., на уровне location'ов) те адреса, где за аутентификацию отвечает nginx, и те, где этим занимается бекенд. [...] > >>кстати, если локейшн описан как ^~, но выше есть другой локейшн на тот же ~ > >>.jpg, все-равно в этой секции не окажемся. > >Это не так. Если у максимально совпавшего статического location'а > >есть модификатор "^~", то регулярные выражения не проверяются. И > >от порядка это не зависит. > location ^~ /aaa/a2/ { > действительно работает > location ^~ /aaa/a(1|2)/ { > уже нет. В таком случае непонятно, почему просто не написать location > /aaa/a2/ и почему не срабатывает признак регэкспа. Потому что "^~" - это не "признак регэкспа". Это, наоборот, запрет на поиск по location'ам, заданным регулярными выражениями, в случае совпадения данного _префиксного_ location'а. Повторю ссылку: http://nginx.org/r/location/ru Настоятельно рекомендую внимательно прочитать описание хотя бы пару раз. -- Maxim Dounin http://nginx.org/ _______________________________________________ nginx-ru mailing list [email protected] http://mailman.nginx.org/mailman/listinfo/nginx-ru
