La mia azienda si è imbattuta in quest'ultimo autunno, a partire da iOS 6, e ciò che è stato possibile accertare è che si tratta di un vero bug di Apple Safari come parte dei suoi "miglioramenti" di sicurezza. Nessuna spiegazione reale da parte loro per motivi logici, ma ecco cosa vediamo negli sniffer di debug e pacchetti.
In condizioni normali, il browser Safari richiede una pagina (o un oggetto nella pagina) dal server su un GET. Se tale risorsa è protetta con una lista di controllo di accesso, nel nostro caso Apache Basic Auth, ed è la prima richiesta su quell'host nella sessione, il server risponderà con un'intestazione di risposta 401 HTTP che indica al client (il browser) che ha bisogno di richiedere nuovamente, questa volta aggiungendo un'intestazione di autenticazione di base con credenziali di autorizzazione. Il browser presenta quindi una finestra di dialogo di accesso all'utente, in cui è possibile immettere le credenziali dell'utente e del passaggio e inviare o annullare la richiesta. Al momento dell'invio, il client richiede nuovamente tali credenziali nell'intestazione auth.
Supponendo che le credenziali siano accettate nella seconda richiesta GET, nella risposta verrà restituito il bene appropriato e il documento nel browser procederà con il caricamento del resto della pagina (presupponendo che si trattasse di una pagina richiesta). Se si dispone di risorse incorporate che risiedono su un host diverso e tale host richiede l'autenticazione per tale risorsa, il processo viene ripetuto al caricamento della pagina.
Ecco dove si rompe. Se incorpori chiamate su oggetti da più di 2 host totali sulla stessa pagina, che richiedono l'autenticazione di base, la terza richiesta di autenticazione su quella pagina viene soppressa, quindi il browser gira per sempre in attesa che tu inserisca le credenziali su un prompt che non vedi mai . Il tuo browser Safari è ora bloccato su quella richiesta di autenticazione bloccata, su questa e qualsiasi altra scheda, anche su una ricarica, e non riceverai un altro prompt a meno che e fino a quando non chiudi il browser o riavvii il dispositivo.
Questo non ha effetto su Chrome, solo Safari, ed è sia su un iPhone che su un iPad con iOS 6 o successivo. Ho l'ultima versione di iOS al momento della stesura di questa (7.0.6), e il problema è ancora lì.
Abbiamo avuto una soluzione alternativa l'anno scorso, in cui avremmo creato una pagina interna con una matrice di ciascuno degli host incorporati, che avremmo poi collegato con un iframe che includeva una chiamata a favicon.ico nella posizione di quell'host . Ciò ha funzionato fino a poco tempo fa, dove ora, forse a causa della funzionalità di iOS 7 del congelamento delle schede di sfondo, i prompt di autenticazione sono di nuovo bloccati.
qui è stato il campione di 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++;
}
Il secondo set nel document.write darebbe un'indicazione visiva di cui sono stati autenticati padroni di casa, come viene ora visualizzata la favicon. Ti consente anche di sapere quale host potrebbe essere bloccato, in quanto manca l'icona.
Poiché questa soluzione alternativa ha smesso di funzionare su iOS 7, l'unica soluzione ingombrante che abbiamo è quella di pre-aprire una scheda separata per ciascuna delle favicon (direttamente nell'URL), immettere l'auth, tornare indietro, passare alla successiva uno nella lista, e ripetere fino a quando non sono state memorizzate tutte le credenziali di autenticazione per tutti gli host utilizzati nella pagina. A quel punto, puoi caricare la pagina originale da quando i tuoi crediti sono ora memorizzati nella cache. Cruddy, e assolutamente irragionevole per un consumatore finale, ma è quello che dobbiamo fare per testare i siti che sono dietro una CDN pubblica, poiché abbiamo bisogno di proteggere le risorse su quel sito di sviluppo con un ACL.
A partire da oggi, stiamo ancora valutando una soluzione migliore. Non è un problema su Android, Windows o qualsiasi altro iOS.
Certo, ha funzionato meglio quando Jobs era vivo.
Spero che un po 'di questo aiuti.
Hai provato a riprodurre questo problema? Almeno saprai se si tratta di un bug di Safari. – Pavlo
Si verifica * solo * nelle app Web aggiunte alla schermata iniziale. Safari (l'app) gestisce correttamente la finestra di autenticazione, ma non riesco a farli funzionare nelle app Web. – oldwren
Abbiamo riscontrato un comportamento simile, vedere la mia domanda http://stackoverflow.com/questions/18976407/broken-basic-authentication-in-web-apps-on-ios-7 –