2010-07-26 13 views
5
  1. Estoy desarrollando un complemento de Google Chrome.
  2. en la página de opciones Estoy ejecutando una solicitud de AJAX al servidor que requiere CONTRASEÑA
  3. Solo quiero detectar el error si la contraseña es incorrecta, pero el navegador muestra una ventana emergente.

alt text http://img834.imageshack.us/img834/2905/browserproblem.pngCómo deshabilitar la ventana emergente predeterminada de la contraseña del navegador?

¿Puedo desactivarlo y cómo?

+0

alguien? tal vez una conjetura? – simple

Respuesta

4

El problema es que no está codificando Base64 el nombre de usuario (es decir, el token de autenticación) y la contraseña (ficticia) que está enviando (que es un requisito del esquema de autenticación HTTP básico). Aquí es más o menos lo que el código debería parecerse a:

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

(. Cambié en 'onsip' como el subdominio para usted, pero usted todavía tiene que reemplazar token con su token de autenticación)

+1

no estoy seguro de que sea el caso intente var xhr = new HMLHttpRequest(); xhr.open ('GET', 'UrlToServerThatUsesBasicHttpAuthentication', true, Login, WrongPassword); xhr.send(); – simple

+0

Lo que byoogle quiere decir es que posiblemente utilices la autenticación basada en POST en 37signals.com en lugar de la autenticación básica basada en GET. – chx

+0

Correcto, debe usar "POST". Obtuve los parámetros anteriores ejecutando un sniffer de paquetes contra la página de inicio de sesión de Highrise, por lo que deben coincidir exactamente con lo que envía la página (si ves el origen de la página, verás que el método de formulario está establecido en "POST" no "GET") Te recomiendo que intentes copiar los parámetros que estoy pasando, ya que funcionan para mí. – oldestlivingboy

0

sé dos maneras uno puede hacer esto en el código Firefox XUL (pero no en el código web), uno de los cuales sé que no se aplica a Google Chrome, y una prueba rápida parece indicar que el otro tampoco lo hace.

Se me ocurren tres opciones.

  1. tener una página de comprobación de contraseñas en un servidor de acceso (lo ideal es el mismo), que cuando se les pregunta (a través de una conexión segura por supuesto) responde con una indicación de si la combinación usuario/pass es correcta. Si usted no es la misma gente que está involucrada con el servidor que ejecuta este servicio, me sentiría agraviado al hacerlo, aunque miles dejan que Facebook y otros. hacer este tipo de cosas todo el tiempo! Por otro lado, es bastante difícil convencer a la gente de no ser tan tonta como para dejar que Facebook y otros. Haga esto todo el tiempo, para que otra persona que haga lo mismo no ayude.
  2. No pregunte a sus usuarios por sus contraseñas, el aviso integrado se usará en todos los casos y será el usuario/pase "normal". Personalmente, me sentiría más feliz con la idea de que estés haciendo incluso Basic, ya que está sobre un canal encriptado de lo que parecería autenticación de formularios (no tan feliz como estaría con Digest u otro modelo con alguna contraseña escondida en el real protocolo) ya que si bien ambos pueden hacer cosas raras y tontas con las contraseñas enviadas, la experiencia ha demostrado que es más probable que los formularios sean creados por alguien que dice "por supuesto que puedo codificar de forma segura, ¿qué hay que pensar?" que cualquier otro esquema.
  3. Si es su propio servidor, puede responder a una contraseña incorrecta con algo distinto de 401, y utilizar esto como una señal en el script para volver a consultar. Sería mejor tener un URI especial de "inicio de sesión" para esto, a fin de no tener este kludge para XMLHttpRequest interferir con los clientes de mejor comportamiento.
+0

Re: # 3, en la mayoría de los navegadores la falta de un encabezado WWW-Authenticate evitará la ventana emergente de autenticación incluso si el estado es 401. Por supuesto, el estado 401 sin encabezado WWW-Authenticate viola la especificación ... pero también lo hace algo diferente a 401 para una falla de autenticación. Es por eso que esto es un kludge. Realmente, el objeto XmlHttpRequest debería tener una configuración para deshabilitar esa ventana emergente ... –

Cuestiones relacionadas