Как отключить всплывающее окно пароля браузера по умолчанию?

Question

1. Я разрабатываю плагин Google Chrome.
2. на странице параметров Я выполняю AJAX-запрос к серверу, который требует ПАРОЛЬ
3. Я просто хочу уловить ошибку, еслиПароль был неверный, но браузер выдает всплывающее окно.

альтернативный текст http://img834.imageshack.us/img834/2905/browserproblem.png

Можно ли его отключить и как?

Answer 1

Проблема в том, что вы не используете Base64-кодировку отправляемого вами имени пользователя (то есть токена аутентификации) и (фиктивного) пароля (что является обязательным требованием для базовой схемы аутентификации HTTP).Примерно так должен выглядеть ваш код:

var xhr = new XMLHttpRequest();
xhr.open('GET', 'http://onsip.highrisehq.com/account.xml');
xhr.setRequestHeader('Authorization', 'Basic ' + btoa(token + ':'));
xhr.onreadystatechange = function() { console.log(xhr.responseText); };
xhr.send();

(я поменял 'onsip' как субдомен для вас, но вам все равно нужно заменить token на ваш токен аутентификации.)

Answer 2

Я знаю два способа, которыми можно сделать это в коде Firefox XUL (но не в веб-коде), один из которых, как я знаю, не применим к Google Chrome, и быстрый тест показывает, что другой тоже не подходит.

Три варианта происходят со мной.

1. Иметь страницу проверки пароля на доступном сервере (в идеале, тот же), который при запросе (конечно же, через безопасное соединение) отвечает с указанием правильности комбинации пользователь / пароль. Если вы не те люди, которые связаны с сервером, на котором запущен этот сервис, я бы огорчился, если вы сделаете это, хотя тысячи позволяют Facebook и соавт. делай такие вещи постоянно! С другой стороны, достаточно сложно убедить людей не быть такими глупыми, чтобы позволить Facebook и соавт. делайте это все время, чтобы другой человек, делающий то же самое, не помог бы.
2. Не спрашивайте своих пользователей о своих паролях, тогда встроенная подсказка будет использоваться в каждом случае и будет «обычным» пользователем / паролем. Лично я бы почувствовал себя счастливее от идеи, что вы делаете даже Basic, так как это по зашифрованному каналу, чем то, что выглядело бы как аутентификация форм (не так хорошо, как я бы с Digest или другой моделью с паролем, скрываемым в реальной протокол), поскольку, несмотря на то, что оба могут делать некоторые странные и глупые вещи с отправленными паролями, опыт показывает, что формы, скорее всего, будут созданы кем-то, идущим "конечно, я могу кодировать безопасно, о чем думать?" чем любая другая схема.
3. Если это ваш собственный сервер, вы можете ответить на неверный пароль чем-то отличным от 401 и использовать его в качестве сигнала в сценарии для повторного запроса. Для этого было бы лучше иметь специальный URI для входа в систему, чтобы не допускать, чтобы этот ключ для XMLHttpRequest мешал клиентам с лучшим поведением.