Senza dubbio ci potrebbero essere molte cause degli stessi sintomi, ma ecco cosa ha risolto questo problema per me.
Avevo solo uno dei tanti PC con Windows 7 con IE11 che mostra il sintomo di "Accesso negato" al tentativo di qualsiasi JavaScript che coinvolge window.localStorage
da siti Web altrimenti affidabili e ben educati. L'utilizzo di Process Explorer ha rivelato che la causa prossimale era un ACCESSO NEGATO quando taskhost.exe (che agisce per conto di Internet Explorer) tentava di aprire DOMStore\container.dat
per lettura-scrittura generica. In effetti, è stato peggio: se ho cancellato container.dat
, si è verificato lo stesso ACCESS NEGATO, anche se il file non esisteva più. E, se ho cancellato la cartella (nascosta) DOMStore
, quando taskhost.exe ha tentato di ricrearlo, ha ricevuto anche l'ACCESSO NEGATO.
Dopo due giorni di caccia di depistaggi, la soluzione finale è stato questo:
La voce del Registro:
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\5.0\LowCache\Extensible Cache\DOMStore\CachePath
(si noti la LowCache
in quella stringa) è stato correttamente impostato:
%USERPROFILE%\AppData\Local\Microsoft\Internet Explorer\DOMStore
quando dovrebbe essere:
%USERPROFILE%\AppData\LocalLow\Microsoft\Internet Explorer\DOMStore
con la conseguenza che le richieste di localStorage a bassa integrità venivano indirizzate a regioni di integrità media della memoria del disco AppData, generando quindi errori DENIED ACCESS e uccidendo l'uso di JavaScript window.localStorage
.
Questa voce del Registro di sistema deve essere stata errata per molti anni: forse un effetto collaterale di utilizzo entusiastico di anteprime di piattaforme buggy e così via. Questo errore è sopravvissuto alla rimozione totale e alla reinstallazione di IE11.
C'è una voce di registro simile di aspetto per la cache di medio integrità:
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\5.0\Cache\Extensible Cache\DOMStore\CachePath
e che viene lasciato come correttamente:
%USERPROFILE%\AppData\Local\Microsoft\Internet Explorer\DOMStore
e non dovrebbe essere cambiata.
Impossibile ripetere, funziona bene qui. Potresti provare a far funzionare una demo su [jsfiddle] (http://jsfiddle.net)? –
Ho la sensazione che potrebbe aver funzionato per te a causa di diverse impostazioni di sicurezza? Proverò a giocherellare con il mio un po 'di più prima di elaborare una demo. Se le tue impostazioni sono diverse, è probabile che la demo funzioni anche per te. Se scopro la risposta, la posterò. –
Ho le cose un po 'ristrette. Quando utilizzo gli Strumenti per sviluppatori F12 su http: // localhost, inserendo un orologio per window.localStorage si verifica un errore Accesso negato. Facendolo su un sito web pubblicamente disponibile (microsoft.com) viene mostrato un oggetto di archiviazione. Quindi è probabile che una demo su jsfiddle non funzioni perché è un sito pubblico. Ho intenzione di provare a pescare nelle impostazioni di sicurezza IE10 tra Internet e Intranet locale per vedere se questo cattura ciò che è diverso. –