How to disable browser default password pop-up?

Question

1. I am developing a Google chrome plugin.
2. under the options page I am running a AJAX request to the server that requires PASSWORD
3. I just want to catch the error if Password was incorrect, but browser is giving a popup window.

Can I disable it and how?

Answer 1

The problem is you’re not Base64-encoding the username (i.e., authentication token) and (dummy) password you’re sending (which is a requirement of the HTTP Basic authentication scheme). Here’s roughly what your code ought to look like:

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();

(I swapped in 'onsip' as the subdomain for you, but you still need to replace token with your authentication token.)

Answer 2

I know two ways one can do this in Firefox XUL code (but not web code), one of which I know doesn't apply to Google chrome, and a quick test seems to indicate the other doesn't either.

Three options occur to me.

1. Have a password checking page on an accessible server (ideally the same one) which when queried (over a secure connection of course) replies with an indication of whether the user/pass combination is correct. If you aren't the same people as involved with the server running this service I'd feel agrieved at you doing this, though thousands let facebook et al. do this kind of thing all the time! On the other hand, it's hard enough convincing people not to be so silly as to let facebook et al. do this all the time, so another person doing the same thing won't help matters.
2. Don't ask your users for their passwords, the built-in prompt will then be used in every case and be the "normal" user/pass. Personally, I'd feel happier with the idea that you are doing even Basic since it's over an encrypted channel than what would look like forms authentication (not as happy as I'd be with Digest or another model with some password hiding in the actual protocol) since while both can do some weird and silly stuff with the passwords sent, experience has shown that forms is more likely to be created by someone going "of course I can code securely, what's to think about?" than any other scheme.
3. If it's your own server, you can respond to an incorrect password with something other than 401, and use this as a signal in the script to re-query. It would be best to have a special "log-in" URI for this, so as not to have this kludge for XMLHttpRequest interfer with better-behaved clients.