javascript - saber - mitrastar dsl-2401hn-t1c movistar

¿Por qué el navegador no vuelve a utilizar los encabezados de autorización después de una XMLHttpRequest autenticada?

Question

Estoy desarrollando la aplicación de una sola página usando Angular. El backend expone los servicios REST que requieren autenticación básica. Obtener index.html o cualquiera de los scripts no requiere autenticación.

Tengo una situación extraña en la que uno de mi vista tiene un <img> donde el src es la URL de una API REST que requiere autenticación. El navegador procesa <img> y no tengo la oportunidad de establecer el encabezado de autorización para la solicitud GET que realiza. Eso hace que el navegador solicite credenciales.

Intenté solucionar esto haciendo esto:

1. Deja img src vacío en la fuente
2. En "documento listo", haga una XMLHttpRequest a un servicio ( /api/login ) con el encabezado Authorization, solo para provocar la autenticación.
3. Luego de completar esa llamada, configure el atributo img src , pensando que para entonces, el navegador sabría incluir el encabezado Autorización en las solicitudes posteriores ...

... pero no es así. La solicitud de la imagen se va sin los encabezados. Si ingreso las credenciales, todas las demás imágenes en la página son correctas. (También he probado Angular''s ng-src pero eso produjo el mismo resultado)

Tengo dos preguntas:

1. ¿Por qué el navegador (IE10) no incluyó los encabezados en todas las solicitudes después de una XMLHttpRequest exitosa?
2. ¿Qué puedo hacer para evitar este problema?

@bergi solicitó detalles de las solicitudes. Aquí están.

Solicitud a / api / login

GET https://myserver/dev30281_WebServices/api/login HTTP/1.1
Accept: */*
Authorization: Basic <header here>
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.2; WOW64; Trident/6.0; .NET4.0E; .NET4.0C; .NET CLR 3.5.30729; .NET CLR 2.0.50727; .NET CLR 3.0.30729)
Connection: Keep-Alive

Respuesta (/ api / login)

HTTP/1.1 200 OK
Cache-Control: no-cache
Pragma: no-cache
Content-Length: 4
Content-Type: application/json; charset=utf-8
Expires: -1
Server: Microsoft-IIS/8.0
X-AspNet-Version: 4.0.30319
X-Powered-By: ASP.NET
Date: Fri, 20 Dec 2013 14:44:52 GMT

Solicitud a / usuario / imagen / 2218:

GET https://myserver/dev30281_WebServices/api/user/picture/2218 HTTP/1.1
Accept: */*
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.2; WOW64; Trident/6.0; .NET4.0E; .NET4.0C; .NET CLR 3.5.30729; .NET CLR 2.0.50727; .NET CLR 3.0.30729)
Connection: Keep-Alive

Y luego el navegador web solicita credenciales. Si los ingreso, obtengo esta respuesta:

HTTP/1.1 200 OK
Cache-Control: public, max-age=60
Content-Length: 3119
Content-Type: image/png
Server: Microsoft-IIS/8.0
X-AspNet-Version: 4.0.30319
X-Powered-By: ASP.NET
Date: Fri, 20 Dec 2013 14:50:17 GMT

Answer 1

Idea básica

Cargue las imágenes a través de JavaScript y visualícelas en el sitio. La ventaja es que las credenciales de autenticación nunca llegarán al HTML. Resistirán en el lado de JavaScript.

Paso 1: cargue los datos de imagen a través de JS

Esa es la funcionalidad básica de AJAX (consulte también XMLHttpRequest::open(method, uri, async, user, pw) ):

var xhr = new XMLHttpRequest();
xhr.open("GET", "your-server-path-to-image", true, "username", "password");

xhr.onload = function(evt) {
  if (this.status == 200) {
    // ...
  }
};

Paso 2: formatee los datos

Ahora, ¿cómo podemos mostrar los datos de la imagen? Cuando se usa HTML, uno normalmente asignaría un URI al atributo src del elemento de imagen. Podemos aplicar el mismo principio aquí, excepto por el hecho de que usamos URI de datos en lugar de http(s):// derivados ''normales''.

xhr.onload = function(evt) {
  if (this.status == 200) {
    var b64 = utf8_to_b64(this.responseText);
    var dataUri = ''data:image/png;base64,'' + b64; // Assuming a PNG image

    myImgElement.src = dataUri;
  }
};

// From MDN:
// https://developer.mozilla.org/en-US/docs/Web/API/window.btoa
function utf8_to_b64( str ) {
    return window.btoa(unescape(encodeURIComponent( str )));
}

Lona

También hay otra opción que consiste en pintar los datos cargados en un campo <canvas> . De esta forma, el usuario no podrá hacer clic con el botón derecho en la imagen (el área donde se coloca el lienzo) en lugar de los <img> y los URI de datos donde el usuario verá un URI de datos largo al visualizar el panel de propiedades de la imagen .

Answer 2

Deberá intentar usar el encabezado Access-Control-Allow-Credentials: true . Una vez encontré un problema con IE que finalmente se redujo al uso de este encabezado. También configure $httpProvider.defaults.headers.get = { ''withCredentials'' : ''true'' } en el código js angular.

Answer 3

El cargador de Google Drive se crea usando angular js. Sus autores se enfrentaron a un problema similar. Los iconos se alojaron en un dominio diferente y ponerlos como img src= violaron el CSP. Por lo tanto, al igual que usted, tuvieron que buscar las imágenes de los iconos con XHR y luego de alguna manera lograron colocarlas en las etiquetas de img .

Describen cómo lo resolvieron . Después de obtener la imagen con XHR, la escriben en el sistema de archivos local HTML5. Ponen su URL en el sistema de archivos local en el atributo src img usando la directiva ng-src .

$http.get(doc.icon, {responseType: ''blob''}).success(function(blob) {
  console.log(''Fetched icon via XHR'');
  blob.name = doc.iconFilename; // Add icon filename to blob.
  writeFile(blob); // Write is async, but that''s ok.
  doc.icon = window.URL.createObjectURL(blob);
  ...
}

En cuanto al por qué, no sé. Supongo que la creación de un token de sesión para recuperar las imágenes está fuera de cuestión. ¿Esperaría que los encabezados de Cookie sean enviados? ¿Es una solicitud de origen cruzado? En ese caso, ¿configura la propiedad withCredentials ? ¿Es algo de P3P quizás?

Answer 4

Me parece que para resolver su problema, debe cambiar el diseño de su aplicación, en lugar de tratar de abrirse paso como los navegadores realmente funcionan.

Una solicitud a una URL segura siempre necesitará autenticación, con respecto a que el navegador la realice con una etiqueta img o en javascript.

Si puede realizar la autorización automáticamente sin la interacción del usuario, puede hacerlo desde el servidor y no necesita enviar ningún + pase al cliente para hacerlo. Si ese es el caso, puede cambiar el código detrás de https://myserver/dev30281_WebServices/api/user/picture/2218 para realizar la autorización y servir la imagen, sin autenticación HTTP, solo si el usuario está autorizado para solicitarla, de lo contrario, devuelve una respuesta prohibida 403 ( http://en.wikipedia.org/wiki/HTTP_403 ).

Otra posible solución sería separar las páginas que incluyen las imágenes seguras del resto de la aplicación. Entonces, teóricamente, tendrías dos aplicaciones de una sola página. El usuario debería iniciar sesión para acceder a la parte segura. Aunque no estoy seguro si esto es posible en su caso, ya que no indicó todos los requisitos. Pero tiene más sentido que, si desea proporcionar recursos seguros que requieren autenticación, se le soliciten credenciales al usuario, tal como lo hace el navegador.

Answer 5

Otro enfoque sería agregar un punto final a la parte posterior de su sitio que procesa la solicitud de imagen. Entonces su página podría solicitarlo sin credenciales y el back-end se encargaría de la autenticación. El back-end también podría almacenar en caché la imagen si no cambiaba con frecuencia o si sabía la frecuencia con la que se actualizaba. Esto es bastante fácil de hacer en el back-end, simplifica la interfaz y evita que se envíen credenciales al navegador.

Si el problema es la autenticación, los enlaces podrían contener un token de uso único generado para el usuario que está autenticado y solo accesible desde su sesión actual del navegador. Brindar acceso seguro al contenido solo para el usuario para el que fue creado y solo durante el tiempo en que esté autorizado para acceder a él. Esto también requeriría trabajo en el back-end, sin embargo.

Answer 6

Siempre analizo

Establecer el valor del encabezado Cookie en la solicitud anterior (o la primera solicitud de inicio de sesión) y luego enviar su valor en las próximas solicitudes.

Algo como esto

Respuesta después de la primera solicitud:

Date:Thu, 26 Dec 2013 16:20:53 GMT
Expires:-1
Pragma:no-cache
Set-Cookie:ASP.NET_SessionId=lb1nbxeyfhl5suii2hfchxpx; domain=.example.com; path=/; secure; HttpOnly
Vary:Accept-Encoding
X-Cdn:Served-By-Akamai
X-Powered-By:ASP.NET

Cualquier próxima solicitud:

Accept:text/html,application/xhtml+xml
Accept-Encoding:gzip,deflate,sdch
Accept-Language:en-US,en;q=0.8,ru;q=0.6
Cache-Control:no-cache
Connection:keep-alive
Cookie:ASP.NET_SessionId=lb1nbxeyfhl5suii2hfchxpx;

Como puede ver, envío el valor ASP.NET_SessionId = "any value" en el encabezado de Cookie . Si el servidor usa php, debe analizar PHPSESSID = "algún valor"