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

[Maxim Dounin <mdounin@xxxxxxxxxx>]

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