Re: Возможность проверить успешность auth_basic авторизации

[Maxim Dounin]

Hello!

On Thu, Feb 15, 2018 at 12:28:56AM +0700, Vadim A. Misbakh-Soloviov wrote:

> Всем привет.
> У меня тут возникла необходимость в проверке успешности auth_basic авторизации 
> (каковая, например, есть для client_certificate ($ssl_client_verify)).
> 
> У меня была идея сделать (средствами NginX) basic-авторизацию (в одном и том 
> же локейшне) необязательной, но принципиально применимой. И в случае 
> предоставления логина-пароля — обрабатывать этот кейс (а точнее - использовать 
> содержимое $remote_user для определённых целей).
> 
> Логичным решением мне показалось использовать `satisfy any`+`allow all`
> +`auth_basic`.
> 
> Однако в данном случае при предоставлении неправильного пароля в $remote_user 
> всё равно оказывается переданное имя пользователя. Что является немного не тем 
> результатом, на который я рассчитывал, но с этим можно было бы смириться (в 
> конце концов, никто и не говорил, что директива содержит имя только в случае 
> успешной авторизации), если бы был способ проверить успешность авторизации. А 
> такового я не нашёл (возможно, плохо искал).
> 
> В общем, подскажите пожалуйста:
> 
> 1) есть ли способ узнать, была ли авторизация успешной? Может, я и в самом 
> деле слепой и не вижу в документации того, что там есть?

Если в конфиге сказано "satisfy any; allow all; auth_basic ...", 
то проверки паролей в соответствии с auth_basic вообще не будут 
выполняться.  Операция проверки IP-адреса дешевле, и делается в 
первую очередь.  Если она говорит, что доступ следует 
предоставить, то доступ предоставляется без каких-либо дальнейших 
проверок.

Соответственно вопрос, была ли аутентификация успешной, в такой 
конфигурации не имеет ответа, так как самой аутентификации - не 
было.

Кроме того, сама http-аутентификация предполагает, что браузер 
отправляет заголовок Authorization в ответ на 401 c 
WWW-Authenticate, и непонятно, откуда она вообще возьмётся в такой 
конфигурации.

> 2) может быть, есть иной способ добиться того, что я хотел кроме `satisfy any`
> +`allow all`?

Я бы не рекомендовал строить подобные системы, но если очень 
хочется - можно попробовать посмотреть в сторону auth_request.

Тут можно либо реализовать любую собственную логику с помощью 
имеющегося интерфейса, либо же схитрить, и воспользоваться тем, 
что auth_request выполняется после auth_basic (что, впрочем, 
implementation detail, так что caveat emptor applies).  В 
результате в конфигурации вида


    location / {
        satisfy any;
        auth_basic secure;
        auth_basic_user_file /tmp/foo;
        auth_request /auth;
        add_header X-Auth $remote_user:$auth_failed;
    }

    location /auth {
        set $auth_failed 1;
        return 204;
    }

всегда будет делаться проверка по auth_basic, и в случае, если 
проверка по auth_basic не была успешна по какой-либо причине - 
переменная $auth_failed будет установлена в 1.

-- 
Maxim Dounin
http://mdounin.ru/