Ran into something lovely, and intermittent, while trying to write cookies today in an Iframe via javascript.
So say I assign a new cookie:
document.cookie = "key=value;";
Calling said cookie returns as:
document.cookie = "";
I've tried this across both IE 9 and IE10, and it's working for some users, and not others. Same browser versions.
Furthermore, it seems to be machine specific, we're in an enterprise network, and users can log into one machine, and be okay, whilest another station and we'll see this behavior.
I've thought about some group policy, but that last point has me at something of a loss.
Edit: More extra details.
Cookies are allowed on these machines.
This isn't a Session/Persistent Cookie mix up; literally trying to write to the document.cookie object returns "", even if you call it right after assignment.
Here's a big one I missed, I'm trying to assign these as an Iframe, and there doesn't seem to be an issue with P3P headers, as there are machines that are viewing it just fine; same browser versions.
I was experiencing the same problem and found that the users with IE that could not take the cookie had protected mode enabled.
Internet Options/Security/Enable Protected Mode (uncheck)
Related
I am trying to get browser cookies through Java Script using document.cookie. When i run my code on different-2 machines, then i am unable to get browser cookies every time.
I checked into browser's developer tool under resource tab, cookies are available there. But unable to get it every time. I mean to say that on one machine i am able to get it, on another machine, i am not able to get.
When i debug my code, i found that document.cookie is returning me a blank string on another machine, although cookies are available in browser.
I am using google chrome with latest version. So i think, there should not be any issues with browser because i can see cookies are available in browsers.
Can someone please help me find that what could be reason for this issue ?
var x = document.cookie;
We have a web app that runs in Facebook (i.e. a running in an iFrame at a different domain). If a Safari user has Cookies and Website Data set to the default, "Allow from websites I visit", the data we store via localStorage.setItem is acting like sessionStorage, i.e. it's not available beyond the user's current session (i.e. after the user closes the tab). If we change the setting to "Always allow", it works fine just like in Chrome, IE , etc.
As a test, we've tried navigating the browser to our app's domain (https://ourappname.appspot.com) directly and it works fine there. And also then it should truly be a visited website, but when going back to the game within Facebook, the problem still exists.
Note that the setItem call is succeeding, it's just that getItem doesn't return anything in a subsequent session. (So it's not like when the user is Private Browsing and the setItem call itself fails with a Quota Exceeded error.)
What do we need to do to support Safari so that our app, running within Facebook, can use localStorage as intended where the data will survive between sessions?
It's either a bug in Safari or a security feature.
You are visiting FaceBook and not your website. Your app is in iframe which would violate security model if it let you read any data from the browser. Think if a competitor site read data it did/didn't set. That'd constitute an information leak.
Safari is doing it's job well in that regard.
Ideally, in "Allow from websites I visit" mode, no browser should let iframes to set data to localStorage; even if every domain has their own storage-sandboxes.
What's troubling me is why are they even letting you write to localStorage from iframe at all (in your 'Allow for only sites I visit' mode)? That might actually be a bug - a information spoof attack enabling bug.
I think it's because security-exceptions were dropped from localStorage in case of not-same-party origin of request. So Safari might actually will not throw error but let it silently fail (in some cases). That's probably why your setItem call is succeeding.
At this point, with the given information, I suspect, sir you are out of luck due to Safari programmers following standard to the letter.
I'm still waiting on a reply from Apple, but it's safe to say we're stuck with this behavior. So Anubhav's answer is accurate, but we still needed a solution.
So as a work around, we created new endpoints on our server for persisting/restoring game state. We only utilize this for Safari, for all other browsers we're still persisting our game state in localStorage.
There is a slight performance penalty for the user. And a slight server cost. Not a sexy solution, but now our Facebook canvas app supports Safari.
I am currently developing a website under IE10 (on Windows 8), using WebSockets in JavaScript. It runs fine under Firefox 18 and Chrome 25, but on IE10 I get a SecurityError when I establish the connection.
What I am doing seems pretty straghtforward :
websocket = new WebSocket('wss://hello.dev.mydomain.net');
But IE doesn't like it :
SCRIPT5022: SecurityError
The script is on "https://test.dev.mydomain.net" (not the real address obviously).
What bothers me is that if I just double-click the file on my local computer (e.g. file://...) it just works. Even worse: if I use fiddler to monitor HTTP traffic... it also works. Whereas there seems to be no connection at all without fiddler, as detailed in the API's specs. (See below.)
Judging by websocket spec, the exception should also appear on Chrome/Firefox... but it does not. So I doubt it has anything related to HTTP/HTTPS. In any case, I am using a wsS socket on a httpS page... Moreover: when I replace the wss address by another valid server found on an online example, it works.
I don't know if this is relevant, but the IP from test.dev.mydomain.net is 10.14.x.x where hello.dev.mydomain.net is 194.247.x.x. I don't know if it could trigger some kind of security on IE only...
One more thing: I have a certificate for *.dev.mydomain.net, IE does not seems to have problems with it. The script originally resides on a server called my.name.dev.mydomain.net, but since I am accessing it from another URL (I got a redirect since we first thought it could have been some kind of Same Origin Policy issue), I don't see how it could matter. At least I hope it does not...
Any idea is welcomed.
EDIT: adding the sites to the trusted zone does not work either.
It looks like IE throws a SecurityError if you're trying to open a websocket on a local (intranet) domain. To overcome this, you may disable IE's automatic algorithm for recognizing local sites. This can be done in Tools > Internet Options > Security > Local Intranet > Sites.
Uncheck all checkboxes (or only a particular one, if you know how exactly your domain did end up in intranet ones).
Note that IE uses (among other things) its proxy settings to determine local sites: if your domain is listed as excluded from proxying in proxy settings, then it will probably be treated as intranet one. This is why WebSockets work if you enable Fiddler: it modifies IE proxy settings and thus the list of intranet sites changes.
I had this problem in Windows7/IE11 after applying a security patch. For Windows10/Edge is the same story.
As this is a local websocket (ws://localhost) you have to add ws:\\localhost\ to Internet Explorer configurations (Tools > Internet Options > Security > Local Intranet > Sites > Advanced).
In Windows 10/Microsoft Edge you will find this configuration in Control Panel > Internet Options.
UPDATE
The address of your webapp (https://test.dev.mydomain.net) must be added to the local intranet zone too. Note that in the image the webapp address should be added.
Well, my question wasn't that successful, so I'll post the "workaround" I found.
I got another address for the website, in 194.247.. too. This, magically, solved it. Guess IE doesn't like mixing local and external stuff and watches the IP.
Anyways, I hope this may come in handy to anyone who's got the same issue.
If you have a solution to solve the "real" issue by configuring IE, let me know :)
Cheers,
Browsers has a websocket limitation. For example Internet Explorer has default limit of websocket connections set to 6 per host header name. the same limitation is set for WinForms WebBrowser component.
The solution is to add values under key Computer\HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\Internet Explorer\Main\FeatureControl\FEATURE_WEBSOCKET_MAXCONNECTIONSPERSERVER in registry. Just add DWORD value with executable name , for example iexplore.exe (or your application executable name if you use Web browser component) and set value from range 2..128
Second option how to solve SecurityException is to create multiple subdomains.
The client hostname/IP Address should be same as server IP/Hostname thats listening to otherwise you would get the above error.
1) Make sure whether server hostname configured to listen at IP/localhost etc andif not explicitly specify the hostname ast server
2) use the same hostname in the client. THis will solve the issue. It worked for me...
I encountered the error (although it did not say the SCRIPT5022 part, rather it just reports "ScriptError"). I got around the issue by clicking on "Trusted Sites" and then adding the machine hosting the remote websocket. Note, to add to trusted sites,
I had to supply the address without the "ws://" part (like just mymahcine.mydomain.com)
I had to uncheck the box that says "Require server verification https:// " option.
After I was done adding the domain, I re-checked the box "Require server verification (https://). I would recommend everyone to do the same. Unchecking the box is only a workaround to add sites that don't begin with https (rather ws:// in my case)
I had the same issue at one of my customer's environment.
It turned out that they had a proxy configuration that did not allow the connection to the WebSocket endpoint directly and did not support the WebSocket protocol.
The temporary solution was to disable using the proxy and everything started working. The long term solution is to edit the proxy's configuration (.pac file) to exclude the address of the WebSocket endpoint.
To disable the proxy, go to: Internet Explorer Options > Connections tab > LAN settings button > un-check Automatically detect settings.
Hope this helps someone.
In addition to making sure that the internet zone is not localhost (as in above answers), ensure that if https is used, then wss should be used.
This is not an issue in other browsers, but IE is abit more finicky.
I'm trying to set session cookie in javascript like this:
document.cookie = 'name=alex; path=/'
But Chrome doesn't delete it even if I quit browser and launch it again.
I checked in Firefox and Opera and both work as intended - they delete session cookie on browser exit.
Is Chrome just ignoring expiration rules?
I checked in multiple OSes and found out that session cookie gets removed on Chrome in Windows XP and Ubuntu, but NOT in Mac OSX Lion.
This can be caused by having Chrome set to Continue where you left off.
Further reading
Bug report: Chrome is not deleting temporary cookies – i.e. not logging me out automatically when I close all browser Windows
Issue 128513 in Chromium: Session Cookies not cleared when Chrome processes closed
Issue 128567: Session only cookies don't delete
I just had the same problem with a cookie which was set to expire on "Browsing session end".
Unfortunately it did not so I played a bit with the settings of the browser.
Turned out that the feature that remembers the opened tabs when the browser is closed was the root of the problem. (The feature is named "On startup" - "Continue where I left off". At least on the current version of Chrome).
This also happens with Opera and Firefox.
I just had this issue.
I noticed that even after I closed my browser I had many Chrome processes running. Turns out these were each from my Chrome extension.
Under advanced settings I unchecked 'Continue running background apps when Google Chrome is closed' and my session cookies started working as they should.
Still a pain in the rear for all of us developers that have been coding expecting that session cookies would get cleared when the user is done browsing.
I had to both, unchecked, under advanced settings of Chrome :
'Continue running background apps when Google Chrome is closed'
"Continue where I left off", "On startup"
This maybe because Chrome is still running in background after you close the browser. Try to disable this feature by doing following:
Open chrome://settings/
Click "Show advanced settings ..."
Navigate down to System section and disable "Continue running background apps when Google Chrome is closed".
This will force Chrome to close completely and then it will delete session cookies.
However, I think Chrome should check and delete previous session cookies at it starting instead of closing.
A simple alternative is to use the new sessionStorage object. Per the comments, if you have 'continue where I left off' checked, sessionStorage will persist between restarts.
This issue is caused because you are using Continue where I left off and Continue running background apps when Google Chrome is closed feature of chrome (currently my version is 96).
Please consider setting those off (to test functionality).
I had the same problem with "document.cookie" in Windows 8.1, the only way that Chrome deletes the cookie was shutting it from task manager (not a really fancy way), so I decided to manage the cookies from the backend or use something like "js-cookie".
Have you tried to Remove hangouts extension in Google Chrome? because it forces chrome to keep running even you close all the windows.
I was also facing the problem but it resolved now.
Go to chrome://settings/content/cookies?search=cookies
Enable Clear cookies and site data when you quit Chrome.
Worked for me
If you set the domain for the php session cookie, browsers seem to hold on to it for 30 seconds or so. It doesn't seem to matter if you close the tab or browser window.
So if you are managing sessions using something like the following it may be causing the cookie to hang in the browser for longer than expected.
ini_set("session.cookie_domain", 'www.domain.com');
The only way I've found to get rid of the hanging cookie is to remove the line of code that sets the session cookie's domain. Also watch out for session_set_cookie_params() function. Dot prefixing the domain seems to have no bearing on the issue either.
This might be a php bug as php sends a session cookie (i.e. PHPSESSID=b855ed53d007a42a1d0d798d958e42c9) in the header after the session has been destroyed. Or it might be a server propagation issue but I don't thinks so since my test were on a private servers.
I just had this problem of Chrome storing a Session ID but I do not like the idea of disabling the option to continue where I left off. I looked at the cookies for the website and found a Session ID cookie for the login page. Deleting that did not correct my problem. I search for the domain and found there was another Session ID cookie on the domain. Deleting both Session ID cookies manually fixed the problem and I did not close and reopen the browser which could have restored the cookies.
The solution would be to use sessionStorage, FYI: https://developer.mozilla.org/en-US/docs/Web/API/Window/sessionStorage
Google chrome has a problem if you set and unset cookie improper way. This is php code. Thought this will give you idea.
Set cookie
setcookie('userLoggedIn', 1, 0, PATH);
Wrong way and will not work (notice PATH is missing)
setcookie('userLoggedIn', 0, time()-3600);
Correct way fixes issue on google chrome
setcookie('userLoggedIn', 0, time()-3600, PATH);
I have two copies of IE7, same exact security settings and same exact builds. Two different machines, both running WinXP. In my application, my cookie headers are being properly sent to the server on one version of IE. No other cookies are being sent in another version.
What are some points to troubleshoot in this scenario?
Try Fiddler to trace what's happening, It's more appropriate (and simpler) than Wireshark for this purpose.
http://www.fiddlertool.com/fiddler/
you may want to get something like wireshark to see what is being sent across the line. FIrebug has some net utilities like this but your problem seems specific to IE. Still, trying another browser couldn't hurt in trying to troubleshoot this issue.
Other items to look for are the advanced properties of the IE installation and the zone that the website is in.
be careful what links you are accessing. It took me almost a day to discover why the same browser sometimes sent the session cookies, and sometimes it didn't.
Accessing the page via http://www.example.com will create different cookies than on http://example.com (without the 'www') because the browser sees them as two different access points:)
Also be careful about your browsers settings..you should make sure they are identical.