Принудительно отображать диалоговое окно HTTP-аутентификации браузера

Уже есть несколько вопросов, которые просят подавить диалоговое окно HTTP-аутентификации браузера, и они, кажется, предполагают, что это диалоговое окно автоматически появляется, когда код ответа 401 и заголовок WWW-Authenticate присутствует в ответе.

Я создаю веб-приложение, которое вызывает RESTful API с использованием Ajax, защищенного базовой HTTP-аутентификацией. Я работаю как над веб-приложением, так и над API.

По умолчанию, когда требуется аутентификация, но ее нет, просто выдается ошибка

{"error":"Authentication required"}

со статусом 404. Однако я хотел бы создать одну конечную точку, /user/login, которая возвращает код 401 и заголовок WWW-Authenticate, когда в запросе нет действительного заголовка Authorization. Я знаю, что это не совсем RESTful, но должно работать.

Теперь я реализовал это, и когда я открываю конечную точку в своем браузере, она работает нормально: отображается диалоговое окно браузера. Однако, когда я запрашиваю конечную точку с помощью Ajax, диалоговое окно не отображается (как в Chromium, так и в Firefox).

Как принудительно отобразить это диалоговое окно с запросом Ajax, если это вообще возможно?

Точный ответ сейчас:

HTTP/1.1 401 Unauthorized
Server: nginx/1.4.6 (Ubuntu)
Content-Type: text/html; charset=UTF-8
Transfer-Encoding: chunked
Connection: keep-alive
X-Powered-By: PHP/5.5.9-1ubuntu4.9
Access-Control-Allow-Origin: http://my-url
Cache-Control: no-cache
Date: Thu, 07 May 2015 12:21:10 GMT
WWW-Authenticate: Basic realm="Please login"

Please login

person Community    schedule 07.05.2015    source источник


Ответы (2)


Создайте веб-страницу «Вход», требующую базовой аутентификации, и ссылку на нее. Он может иметь перенаправление мета или JavaScript обратно в ваше основное приложение; перенаправление будет применяться только после того, как пользователь аутентифицируется.

В качестве альтернативы вы можете просто запросить имя пользователя и пароль с помощью JavaScript и отправить их с последующими вызовами Ajax (см. https://stackoverflow.com/a/9613117/18706).

person mahemoff    schedule 07.05.2015
comment
Я выбрал второй подход, но не хотел хранить имя пользователя и пароль локально по соображениям безопасности. Итак, я реализовал конечную точку токена в API, для которой требуется пароль. Токен действителен в течение некоторого времени, может использоваться для входа в систему и может храниться локально в файле cookie. Пользователь имеет возможность привязать токены к своему IP. Для важных действий, таких как изменение адреса электронной почты и пароля, мне по-прежнему требуется аутентификация по паролю (аналогично режиму sudo на GitHub), так что кража файлов cookie не представляет большой проблемы. В любом случае, спасибо! - person ; 12.05.2015
comment
Да, обмен токенами имеет смысл для повышения безопасности. - person mahemoff; 13.05.2015

В качестве (временного?) обходного пути я теперь перенаправляю пользователей в API, которому я даю параметр redirect, на который пользователь перенаправляется обратно после успешной аутентификации.

person Community    schedule 07.05.2015