La authentication HTTP en iOS 7 aplicaciones web no responde

Mi organización tenía una aplicación web que funcionaba perfectamente en iOS 6. Visitaría el website, el website le diría que agregue la página a su pantalla de inicio y, afortunadamente, se agrega una agradable aplicación web HTML5 a la pantalla de inicio.

Debido a que estamos procesando datos confidenciales, la aplicación web usó la authentication HTTP (a través del dialog nativo de authentication WebKit) para autenticar usuarios / pases. Funcionó sin problemas hasta iOS 7. Ahora cuando alguien intenta invocar el dialog de authentication HTTP, no pasa nada. Está claro que está intentando cargar algo, ya que aparece la ruleta en la barra de estado, pero no aparece ningún dialog, básicamente rompiendo la "aplicación".

¿Se ha encontrado alguien mas con esto? ¿Esto es algo que consideras un error en el final de Apple? ¿Alguna solución?

Mi compañía se topó con este último otoño, comenzando con iOS 6, y lo que hemos podido comprobar es que es un error genuino de Apple Safari como parte de sus "mejoras" de security. No hay una explicación real de ellos para la justificación, pero esto es lo que vemos en los rastreadores de packages y debugging.

En el funcionamiento normal, el browser Safari solicitará una página (o un object en la página) del server en un GET. Si ese activo está protegido con una Lista de control de acceso, en nuestro caso Apache Basic Auth, y es la primera request en ese host en la session, el server responderá con un encabezado de respuesta HTTP 401 indicando al cliente (el browser) que necesita solicitar nuevamente, esta vez agregando un encabezado de authentication básico que tiene cnetworkingenciales de autorización. A continuación, el browser presenta un dialog de inicio de session para el usuario, donde puede ingresar al usuario y pasar las cnetworkingenciales, y enviar o cancelar la request. En el envío, el cliente vuelve a solicitar con esas cnetworkingenciales en el encabezado de authentication.

Suponiendo que las cnetworkingenciales se acepten en la segunda request GET, se devolverá el activo correspondiente en la respuesta, y el documento en el browser procederá a cargar el rest de la página (suponiendo que se tratara de una página solicitada). Si tiene activos embeddeds que residen en un host diferente y ese host requiere authentication para ese activo, el process se repite a medida que se carga la página.

Aquí es donde se rompe. Si incrusta llamadas a objects de más de 2 hosts totales en la misma página, lo que requiere authentication básica, se suprime el 3er aviso de authentication en esa página, por lo que el browser gira siempre esperando que ingrese las cnetworkingenciales en un post que nunca verá . Su browser Safari ahora se cuelga en ese post de authentication estancado, en esta y en cualquier otra pestaña, incluso en una recarga, y no recibirá otro post a less y hasta que cierre con fuerza su browser o reinicie su dispositivo.

Esto no afecta a Chrome, solo Safari, y está tanto en un iPhone como en un iPad con iOS 6 o posterior. Tengo la última versión de iOS a partir de este escrito (7.0.6), y el problema sigue ahí.

Tuvimos una solución el año pasado, donde creamos una página interna que tenía una matriz de cada uno de los hosts integrados, que luego recorreríamos con un iframe insertando una llamada al favicon.ico en la location de ese server. Eso funcionó hasta hace poco, donde ahora, tal vez debido a la function iOS 7 de congelar tabs de background, las indicaciones de authentication se vuelven a congelar.

Aquí estaba el ejemplo de JavaScript:

hosts=["store","profile","www","secure-store","images","m","modules"]; devhost=location.hostname; var i=0; while (hosts[i]) { newhost=devhost.replace('store.mydomain',hosts[i]+'.mydomain'); document.write("<iframe Xhidden seamless=seamless width=0 height=0 src=http://"+newhost+"/favicon.ico><img height='16' width='20' alt='NOT' title='NOT AUTHENTICATED' src=http://"+newhost+"/favicon.ico> Authenticated on "+newhost+"</a></br></iframe>"); document.write("<img height='16' width='20' alt='NOT' title='NOT AUTHENTICATED' src="+(newhost.indexOf('secure')>0?'https://':'http://')+newhost+"/favicon.ico> Authenticated on "+newhost+"</a></br>"); i++; } 

El segundo set en el file document.write daría una indicación visual de qué hosts se han autenticado, ya que ahora se muestra su favicon. También le permite saber qué host puede estar estancado, ya que falta su ícono.

Dado que esta solución dejó de funcionar en iOS 7, la única solución engorrosa que tenemos es abrir previamente una pestaña por separado para cada uno de los favicons (directamente en la URL), ingresar la authentication, volver atrás, pasar a la siguiente en la list , y repita hasta que haya almacenado en caching todas las cnetworkingenciales de authentication para todos los hosts utilizados en la página. En ese momento, puede cargar la página original, ya que sus files están ahora almacenados en caching. Cruddy, y completamente irracional para un consumidor final, pero es lo que tenemos que hacer para probar los sitios que están detrás de un CDN público, ya que necesitamos proteger los activos en ese sitio de desarrollo con un ACL.

A día de hoy, todavía estamos descubriendo una solución mejor. No es un problema en Android, Windows o cualquier otro iOS.

Seguro que funcionó mejor cuando Jobs estaba vivo.

Espero que algo de esto ayude.

Tengo exactamente el mismo problema. La authentication básica funcionó con las versiones anteriores de iOS, pero no con iOS 7 en combinación con las aplicaciones web agregadas a la pantalla de inicio. Creo que esto puede estar relacionado con el problema de dialog descrito aquí .

Los cuadros de dialog estándar no funcionan en absoluto, como alertas, confirmar o preguntar.

La request de inicio de session que se muestra para autenticar al usuario probablemente esté bloqueada (no funciona o no está visible) y es por eso que la aplicación web no pasa por la fase de authentication.

Supongo que Apple tendrá que corregir este error en un futuro lanzamiento.

Editar: después de actualizar a iOS 7.0.3, la authentication básica comenzó a funcionar repentinamente también en el modo de la aplicación web de la pantalla de inicio. Se muestra el post de inicio de session y todo funciona como se esperaba.