Come disabilitare la finestra popup predefinita del browser?

Question

1. Sto sviluppando un plug-in di Google Chrome.
2. nella pagina delle opzioni Sto eseguendo una richiesta AJAX al server che richiede PASSWORD
3. Voglio solo rilevare l'errore se la password non è corretta, ma il browser sta dando una finestra popup.

alt text http://img834.imageshack.us/img834/2905/browserproblem.png

Posso disattivare e come?

Answer 1

Il problema è che non si sta codificando in Base64 il nome utente (ad esempio, token di autenticazione) e la password (fittizia) che si sta inviando (che è un requisito dello schema di autenticazione di HTTP Basic). Ecco più o meno ciò che il codice dovrebbe essere simile:

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

(. Ho scambiato nel 'onsip' come il sottodominio per te, ma hai ancora bisogno di sostituire token con il token di autenticazione)

Answer 2

Conosco due modi uno può farlo nel codice XUL di Firefox (ma non nel codice Web), uno dei quali so che non si applica a Google Chrome, e un test rapido sembra indicare che anche l'altro non lo è.

Tre opzioni mi si presentano.

1. Avere una pagina di controllo di password su un server accessibile (idealmente la stessa), che quando interrogato (attraverso una connessione sicura, naturalmente) risponde con un indicazione se la combinazione utente/pass è corretta. Se non siete le stesse persone coinvolte con il server che esegue questo servizio mi sentirei grato per questo, anche se migliaia di persone hanno lasciato Facebook et al. fai questo genere di cose tutto il tempo! D'altra parte, è abbastanza difficile convincere le persone a non essere così sciocco da lasciare che Facebook et al. fai questo sempre, quindi un'altra persona che fa la stessa cosa non ti aiuterà.
2. Non chiedere agli utenti le loro password, il prompt integrato verrà quindi utilizzato in ogni caso e sarà l'utente/passaggio "normale". Personalmente, mi sentirò più felice con l'idea che stai facendo anche Basic poiché è su un canale criptato rispetto a quello che sembrerebbe un'autenticazione di moduli (non così felice come sarei con Digest o un altro modello con qualche password nascosta nell'attuale protocollo) poiché, mentre entrambi possono fare alcune cose strane e sciocche con le password inviate, l'esperienza ha dimostrato che è più probabile che le forme vengano create da qualcuno che sta "certo che posso codificare in modo sicuro, a cosa devo pensare?" di qualsiasi altro schema.
3. Se si tratta del proprio server, è possibile rispondere a una password errata con qualcosa di diverso da 401 e utilizzarlo come segnale nello script per ri-interrogare. Sarebbe meglio avere uno speciale URI di "login" per questo, in modo da non avere questo kludge per XMLHttpRequest che interferisce con i client meglio comportati.