Yesterday I installed Windows 8 and am now trying to understand why I am getting an "Access Denied" message when accessing localstorage. The page is being served on the same PC with the browser (http://localhost). My feeling is that one of the security settings in IE 10 is wrong, but I haven't figured out which one.
The line of JavaScript code triggering the error is:
if(window.localStorage.getItem('phone') == null)
The code works fine in the latest version of Chrome.
Our users were having issues with web sites using the LocalStorage feature (including Twitter) on Windows 8 with IE 10. When accessing one of these sites with the F12 Developer Tools open, a SCRIPT5: Access is denied message appeared on the console.
After working with Microsoft support, we identified the cause. It turned out to be a problem with the settings on the C:\Users\username\Appdata\LocalLow folder in their user profile.
Each folder on your computer has an integrity setting. More information about the purpose of this setting is here: http://msdn.microsoft.com/en-us/library/bb625964.aspx
The integrity setting on the AppData\LocalLow folder (and its subfolders) in each user's profile is supposed to be set to "Low" (hence the name). In our case, the integrity level was not set correctly on this folder. To rectify the problem, run the following command in a command prompt window:
icacls %userprofile%\Appdata\LocalLow /t /setintegritylevel (OI)(CI)L
(If there is more than one user account on the computer and the other users are having the same issue, the command needs to be run under each affected user's account.)
As for how this setting got changed in the first place? In our case, it was caused by a problem in the customized Windows 8 image we deployed to our workstations. For others that are having the issue, my research has revealed that the use of a "system cleaner" utility may be to blame.
Doubtless there might be many causes of the same symptoms, but here is what fixed this issue for me.
I had just one of many Windows 7 PCs with IE11 exhibiting the symptom of "Access Denied" on attempting any JavaScript involving window.localStorage from otherwise reputable and well-behaved web sites. Use of Process Explorer revealed that the proximal cause was an ACCESS DENIED when taskhost.exe (acting on behalf of Internet Explorer) tried to open DOMStore\container.dat for Generic Read-Write. In fact, it was worse than that: if I deleted container.dat, the same ACCESS DENIED occurred, even through the file did not exist any more. And, if I deleted the (hidden) DOMStore folder, when taskhost.exe attempted to recreate it, that received ACCESS DENIED as well.
After two days of chasing false leads, the final solution was this:
The registry entry:
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\5.0\LowCache\Extensible Cache\DOMStore\CachePath
(do note the LowCache in that string) was incorrectly set to:
%USERPROFILE%\AppData\Local\Microsoft\Internet Explorer\DOMStore
when it should be:
%USERPROFILE%\AppData\LocalLow\Microsoft\Internet Explorer\DOMStore
with the consequence that low-integrity localStorage requests were being directed to medium-integrity regions of AppData disk storage, thus generating ACCESS DENIED errors, and killing the use of JavaScript window.localStorage.
This registry entry must have been wrong for many years: perhaps a side-effect of enthusiastic take-up of buggy platform previews and so on. This error survived a total removal and re-installation of IE11.
There is a similar-looking registry entry for the medium-integrity cache:
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\5.0\Cache\Extensible Cache\DOMStore\CachePath
and that is correctly left as:
%USERPROFILE%\AppData\Local\Microsoft\Internet Explorer\DOMStore
and should not be changed.
Try enabling the Enhanced Protected Mode in the IE settings, under the Advanced tab, in the Security sub-list. This enables the Microsoft XSS filter. I had similar issues when logging into SE, and fetching google+ notifications, and my first workaround was starting IE with admin privileges. But I think the EP mode will do the trick in your case too.
Related links: Understanding Enhanced Protected Mode
Mark Russinovich always says: "when in doubt, use Process Monitor":
localStorage data gets stored in XML files in the following folder:
C:\Users\[USERNAME]\AppData\Local\Microsoft\Internet Explorer\DOMStore
A profile of the file activity while reproducing the issue can tell you if the problem is caused by missing file access permissions or maybe even an anti-virus program.
I can reproduce the error by adding the read-only attribute to "DOMStore\container.dat". You should check if all file/folder permissions and attributes are set correctly. On my machine, admins and my own account have full permission for the mentioned folder.
Go to Tools/Internet Options/Advanced and under 'Security' select 'Enable DOM Storage' checkbox. This should fix the problem
I added the websites involved to the Trusted Sites section of IE and have not received the error again.
In addition to the already excellent answers here, I'd like to add another observation. In my case, the NTFS permissions on the Windows %LOCALAPPDATA% directory structure were somehow broken.
To diagnose this issue. I created a new Windows account (profile), which worked fine with the localStorage,so then I painstakingly traversed the respective %LOCALAPPDATA%\Microsoft\Internet Explorer trees looking for discrepancies.
I found this gem:
C:\Users\User\AppData\Local\Microsoft>icacls "Internet Explorer"
Internet Explorer Everyone:(F)
I have NO idea how the permissions were set wide open!
Worse, all of the subdirectories has all permissions off. No wonder the DOMStore was inaccessible!
The working permissions from the other account were:
NT AUTHORITY\SYSTEM:(OI)(CI)(F)
BUILTIN\Administrators:(OI)(CI)(F)
my-pc\test:(OI)(CI)(F)
Which matched the permissions of the parent directory.
So, in a fit of laziness, I fixed the problem by having all directories "Internet Explorer" and under inherit the permissions. The RIGHT thing to do would be to manually apply each permission and not rely on the inherit function. But one thing to check is the NTFS permissions of %LOCALAPPDATA%\Microsoft\Internet Explorer if you experience this issue. If DOMStore has broken permissions, all attempts to access localStorage will be met with Access Denied.
This issue may also be caused by having missing or corrupted registry entries. If a reset does not resolve the issue, the LocalLow folder has the correct integrity level, and the DOMStore registry value is correct, run the below commands to re-register IE in the profile:
32 Bit OS:
C:\WINDOWS\system32\ie4uinit.exe -BaseSettings
64 Bit OS:
C:\WINDOWS\system32\ie4uinit.exe -BaseSettings
C:\Windows\SysWOW64\ie4uinit.exe -BaseSettings
See the IE MSDN blog for more details.
Related
The main idea is to run a random page on Internet Explorer and get javascript errors and logs.
Is there a way to recover javascript console logs and execution error
from a random web page without accessing the F12 tool on Internet
Explorer?
I found that with Chrome based browser, you can get it on your AppData file log by adding --enable-logging --v=1 args when launching.
Any solution with any language are welcome.
Thank you for your answer.
NOTE :
random page on Internet Explorer means that I do not have the access on the source code.
Basic solution to this would be:
1. Use Exception Handling to catch the errors.
2. Log errors in a Global Array
3. Log the errors in a file using Blob and URL.createObjectURL. All recent browsers support this.
Have you considered using a Bookmarklet that:
Overrides window.console.log and window.console.error (to intercept messages)
Logs incoming messages somewhere using createObjectURL?
Or you could use something like firebuglite and auto-enable it like this:
<script type="text/javascript" src="https://getfirebug.com/firebug-lite.js">
{
overrideConsole: false,
startInNewWindow: true,
startOpened: true,
enableTrace: true
}
</script>
More instructions are here: http://getfirebug.com/firebuglite
If the F12 tool is not of your interest, then what about the Event Viewer? Open Event Viewer from Control Panel -> System and Security -> Administrative Tools -> Event Viewer. Then select the log Applications and Services Logs\Internet Explorer.
By default no events are being logged for Internet Explorer, to enable them create a new DWORD registry value named Feature_Enable_Compat_Logging under the following registry key:
HKCU\SOFTWARE\Microsoft\Windows\Internet Explorer\Main \FeatureControl
and set the registry value to 1.
Check the logs you get to see if it's what you're looking for.
One idea would be to write a browser extension which listens for window.onerror and writes to a file. Definitely not as elegant as the Chrome solution, but it would work fairly well.
Using local proxy might be a good one-time solution.
Charles web debugging proxy app has nice UI and it allows to replace any response with local resource.
So basically you'll need:
Download one any of the js files used on target page
add any code you wish to saved version
set up Charles to serve you your local version instead of remote one
You might try Fiddler. It's got its own logging and has amazing inspection power. It won't capture IE specific errors, since it's at a different layer, but it will definitely get you any code that's coming over the wire.
MS CRM 2011 on premise.
No problems if accessed via internal address: crm:5555
Go to crm.ourcompany.co.uk:5555 in IE and load account page and the ribbon is totally grey. (Not disabled - every pixel is the colour grey.)
In Chrome and Firefox the ribbon is loaded fine.
Browser console in IE, Chrome and FF all say access errors.
I can see they are trying to access crm:5555.
IE says:
SCRIPT5: Access is denied.
PageLoader.js, line 1 character 1226
The second line above is presented as a link. Clicking it shows me this: http://pastebin.com/bBadk9HS
The full path is http://crm.ourcompany.co.uk:5555/_static/_common/scripts/PageLoader.js?ver=-1056260279
P.S. IE is "Browser Mode: IE10 Document Mode: IE9 standards".
After Long investigation I have found out the reason for same issue like this.
We had previous rollup activity feed solution.
After importing the new version of Activity feeds this hectic issue was sorted out.
Activity feed new solution is available with rollup up package.it can be found by exacting the rollup package. Previously this was available in Microsoft Dynamic market place.
It turns out that the problem is an address lookup plugin on the Account form.
This is trying to access http://crm:1999, which is a 404, and http://crm:5555, which isn't allowed.
Solutions are to fix the server on http://crm:1999 and set up proper managed internal and external URLs so it'll know whether http://crm:5555 or http://crm.ourcompany.co.uk:5555 or remove the plugin.
I'm working on a client issue where Modernizr unexpectedly does not detect the support for the localStorage object in Internet Explorer 9. My page correctly uses the HTML 5 doctype (<!DOCTYPE html>) and the developer tools report the page has a Browser Mode of IE9 and a Document Mode of IE9 standards so I would expect this to work.
I've debugged into the following try/catch block in Modernizr and discovered a JavaScript error is thrown as soon as the localStorage object is accessed.
tests['localstorage'] = function() {
try {
localStorage.setItem(mod, mod);
localStorage.removeItem(mod);
return true;
} catch(e) {
return false;
}
};
On some machines the message of the JavaScript error is The system cannot find the file specified.. On others it is just Invalid argument. and Internet Explorer blocks for exactly 5 minutes before it throws the error.
What is causing accessing the localStorage object to throw an error here on Internet Explorer?
I've discovered if the lowest level subdomain matches one of the reserved device names as documented at Restrictions on the File Mask and File Name Properties on Internet Explorer then accessing the localStorage object will throw an error.
This problem is likely happening because internally Internet Explorer is attempting to access the file system using a reserved device name when accessing the localStorage object in order to satisfy the Storage object initialization steps.
It's certainly very much an edge case but if your page is comes from a server whose lowest level subdomain is exactly any of con, prn, aux, clock$, nul, com1, com2, com3, com4, com5, com6, com7, com8, com9, lpt1, lpt2, lpt3, lpt4, lpt5, lpt6, lpt7, lpt8, or lpt9 (e.g. http://prn.example.com) then this could well the reason why you are seeing this problem.
Choosing a lower level subdomain that wasn't a reserved device name in this situation solved the problem.
We hit a similar issue because we ran CCleaner on the machine.
To solve:
Internet Options -> Browsing History -> Delete:
Make sure to check all options except the very first one (Preserve Favorite website data).
We were able to fix, then reproduce this issue by using CCleaner again, then fix again.
Go to this site for more information: http://grekai.wordpress.com/2013/02/24/localstorage-the-system-cannot-find-the-path-specified/
I am using library called arbor.js(beautified). It contains the following line of code,
i = new Worker(<path to arbor.js>);
At this point an error is thrown, and the following message is reported in Firebug,
"Could not get domain!"
The line which gives this error is 258. The arbor_path() function on that line returns "js/", so effectively function called is i = new Worker("js/arbor.js").
This used to work perfectly in Firefox 7. Does anybody know how to solve it, or what the problem could be?
You're running into https://bugzilla.mozilla.org/show_bug.cgi?id=683280
It'll be fixed in Firefox 9 in about a month....
I came across the same thing, however I only noticed the problem on one of my computers, and not the other (both running Firefox 8), so I started to explore a little bit. It turns out, the computer the workers were working on is using a subdomain of localhost (and modified HOSTS file). I just tested it out as simply as I could think of, just adding localhost.com to the HOSTS file, and accessing the site through that and the workers are doing ok with it. I didn't create any virtual hosts or directories, just mapped localhost.com to 127.0.0.1. If you are running on Windows (or otherwise can do the same kind of mapping) you might want to give that a try as a temporary solution.
Edit: In response to chinmayv's comment: Something I noticed I have set in the HOSTS file is the IPv6 version of the local IP address, so there is both: ::1 localhost and 127.0.0.1 localhost, as well as the one to get the worker running on FF8 127.0.0.1 localhost.com. I don't know why this would matter, however. I just did a fresh install of Apache, so I don't think there is any setting that could account for the difference in behavior. Are you still getting the 'Could not get domain!' error? Maybe there is an absolute URL in the script somewhere that is throwing it off?
I am getting (NS_ERROR_DOCUMENT_NOT_CACHED) error when I try to access the Javascript code through firefox.I get this error in the contents tab of HTTPFOX.
I googled and set the parameters of browser in config file as specified in this site but it still doesn't work.
http://code.google.com/p/httpfox/issues/detail?id=20
Can somebody suggest whats going wrong since the same code works fine for safari browser..
If anyone is interested in a solution to this, I believe it's to do with the plugin noscript. Disabling it fixed this, but I have yet to work out what part of noscript was causing the issue. Will update if I find out.
Edit:My issues was with a twitter auth callback. In the Advanced settings of noscript under ABE, in the SYSTEM ruleset, on the line "Accept from LOCAL" I added "*.twitter.com". This allowed callback requests from *twitter.com to return to a local address.
On my macbook I had to uninstall firefox completely to correctly get the content of an ajax response with httpfox. This also implies to remove the firefox profile bij removing this Firefox folder (I could only find it via the terminal and not via Finder):
/Users/<YOURUSER>/Library/Application Support/Firefox
Then install firefox again and install the httpfox add-on.
I tried many cache settings also by entering about:config in the firefox URL however without succes. Be aware that removing the profile settings like I describe will also remove all your personal firefox customization. It concerned firefox 18.0.2 and httpfox 0.8.11.
We used to get the same error when our JavaScript made an XMLHTTPRequest to the server. On the server side, we had java, and the java response, the content type was not explicitly set to "text/html". When that was done
resp.setContentType("text/html");
the error went away.