We have an ASP.NET application that uses Forms Auth. When users log in, a session ID cookie and a Forms Auth ticket (stored as a cookie) are generated. These are session cookies, not permanent cookies. It is intentional and desirable that when the browser closes, the user is effectively logged out.
Once a user logs in, a new window is popped up using window.open('location here');. The page that is opened is effectively the workspace the user works in throughout the rest of their session. From this page, other pop-ups are also used.
Lately, we've had a number of customers (all using latest versions of IE8) complaining that the when they log in, the initial pop-up takes them back to the log in screen rather than their homepage. Alternately, users can sometimes log in, get to the homepage (which again, is in a new pop up window), and it all seems fine, until any additional pop-ups are created, where it starts redirecting them to the log in screen again.
In attempting to troubleshoot the issue, I've used good old Fiddler. When the problem starts manifesting, I've noticed that the browser is not sending up the ASP.NET session ID session cookie OR the Forms Auth ticket session cookie, even though the response to the log in POST clearly pushes down those cookies.
What's more strange is if I CTRL+N to open a new window from the popped-up window that is missing the session cookies, then manually type in the URL to the home page, those cookies magically appear again. However, subsequent window.open(); calls will continue to be broken, not sending the session cookies and taking the user to the log in screen.
It's important to note that sometimes, for seemingly no good reason, those same users can suddenly log in and work normally for a while, then it goes back to broken.
Now, I've ensured that there are no browser add-ons, plug-ins, toolbars, etc. are running. I've added our site as a trusted site and dropped the security settings to Low, I've modified the Cookie Privacy policy to "accept all" and even disabled automatic policy settings, manually forcing it to accept everything and include session cookies. Nothing appears to affect it.
Also note the web application resides on a single server. There is no load balancing, web gardens, server farms, clusters, etc. The server does reside behind an ISA server, but other than that it's pretty straight forward.
I've been searching around for days and haven't found anything actionable. Heck, sometimes I can't even reproduce it reliably. I have found a few references to people having this same problem, but they seem to be referencing an issue that was allegedly fixed in a beta or RC release (example: IE8 loses cookies when opening a new window after a redirect). These are release versions of IE, with up-to-date patches.
I'm aware that I can try to set permanent cookies instead of session cookies. However, this has drastic security implications for our application.
Update
It seems that the problem automagically goes away when the user is added as a Local Administrator on the machine. Only time will tell if this change permanently (and positively) affects this problem.
Time to bust out ProcMon and see if there is a resource access problem.
Update #2
It seems there are multiple angles to what appears to be a singular problem. I reported long ago that making the user a local administrator seemed to help. And it did, for a number of users. Of course, that's not really a solution, but it did let us hobble along.
Then more users started reporting the issue, and the admin fix was not helping. The users seemed to be mostly Win7, but Vista was also affected. They also seemed to mostly be 64-bit installations.
Setting the TabProcGrowth to 0 or 1 (either worked) as suggested by some members below seems to have largely addressed the issue. So, I'm going to move my accepted answer to the first person that suggested that, as it has had significantly more impact.
This has been an incredibly frustrating issue to attempt to solve, since it is difficult to reproduce and often occurs with users that I do not have direct communication with, or by the time I get to them it doesn't appear to be working. All I can say is something is not right with the session merging feature, but I don't have much data to feed to Microsoft to find a permanent fix.
This is 'new' functionality in IE8!
Checkj out the IE8 blog below to read about it.
http://blogs.msdn.com/askie/archive/2009/03/09/opening-a-new-tab-may-launch-a-new-process-with-internet-explorer-8-0.aspx
IE8 can use multiple processes for handling an x number of IE windows. When you cross a process space, you loose your cookies (Asp.Net session ID seems to be retained over this process boundry).
I personally think it's broken or a bug. As we know, when browing to the 'same domain target' cookies should be maintained and resent. That IE8 has different processing behavior for security.. Great! that it is behaving badly and 'drops cookies even if going to the same target domain in another window' is just a bug in my view.
You can modify the number of processes IE8 uses through the internet explorer options ehh.. modifying a registry setting!!!!!! (this is what makes it a bug in my view. IE providing a UI to modify these settings would make it 'enterprise level acceptable'.
Regard,
Marvin Smit
There are multiple possibilities behind this -
UAC & Vista (Had to crop up!!). Specifically, look for protected mode behavior.
This could be an actual problem with the Session Merging feature in IE8. More so because opening a new window via the Ctrl+N shortcut causes the cookies to be magically sent in your case.
An issue with an older build of IE (I know you have stated that your customers are using the latest build). You might want to check the details available at Microsoft Connect for bug IDs 408806 and 392032.
We solved this problem by changing the "Set tab process growth" to 0.
Although, we didn't have protected mode turned on and the zone was "Intranet". Evidently this is a problem/bug with Windows 7 64Bit as others have stated.
This page (#4) lead me to the solution: http://blog.httpwatch.com/2009/04/07/seven-things-you-should-known-about-ie-8/
Near as I can tell, another change to cookies across tabs just went live in this security update from November 12, 2013 that is breaking functionality in our app in all versions of IE. We're doing OpenID auth in a popup window so as to not have to redirect the user away from the page they were browsing when they first clicked the Login link. The session cookie for the login is correctly being sent down in the request in the popup window, but it never gets seen by the main browser window, so the next request to the server doesn't have that session cookie on it like it should, and thus logging in never actually works.
Does anyone have any possible solutions to this?
We had this problem on IE6,7 and 8 .The scenario is parent window(1) opens a modal window(2),modal window has a link to a non-modal window (3). I used to get a different session Id in the 3rd window.
Workaround mentioned here fixed the issue http://support.microsoft.com/kb/831678
Since IE8 we (and our customers) are also experiencing the same issue. We have an asp service for creating forms. This application uses new windows for adding elements or managing user accounts e.g. Randomly (when opening a new window), the application doesn't get the required session id for authentication allong with other 'permanent' cookies. Hence, the session id is a temporary cookie. Most of the time it goes well, but other times the session is broken every time a new window is opened. We have to advise our customers to close all IE windows and start over again.
As a web developer I use IE extensively. Personally, I am not experiencing the above issue. But I think a related one. A few times a day IE totally hangs (does not respond anymore) when opening a new window. When I kill a certain IE process using the task manager, IE starts responding again. But in most cases it's better to start all over with a clean new instance of IE. For this reason I just kill the process with the least ram usage which causes all IE processes to quit.
Microsoft saying these issues/bugs are squashed in the final version does not give me trust of their effort solving the issue still be experienced.
I also found a workable fix for this problem. There seems to be a problem with how IE8 handles opening servlets in another window with a relative path such as /test. It seems to be opening a new session as well as a new window. Our workable fix is that instead of opening a new window with a relative path, we just used a jsp page. So when we navigate to a URL, we do not navigate to /test anymore.We navigate to a specific file. In the jsp file, we forward the request to the relative path. This seems to work, which is kind of awkward, since the only difference is that we are placing a specific file in between.
I hope this helps.
I know this problem since IE 5, so I only use session's variables in modal pop-up windows...
When I open a non-modal pop-up window, I replace all session's variables with ASP.NET cache and new object collections...
But it's very tiresome!
Other browsers (i.e. Firefox) don't have this problem...
I believe this is actually a bug in IE; I have reported it here to see what feedback I get: http://social.msdn.microsoft.com/Forums/en-US/83bb3b91-1c1f-4d51-9281-9bc5f51d3640/log-in-fails-cookie-is-not-sent-to-originating-tab?forum=iewebdevelopment
I have a similar, though not identical problem. We load a webpage that opens a popup with window.open() into an IE browser control. On machines that have either IE6 and IE8, the popup window is always assigned a new SessionID by ASP when launched from the control. However, when launched from a normal browser (IE or Firefox), the popup window gets the existing SessionID.
I can see when launching from the control that a new iexplore.exe process is spawned; thus the session loss behavior makes sense given what has been mentioned about in-memory cookies not being carried over to the new process.
I'm still trying to figure out a workaround myself ...
Update
Figured out a workable fix! It is possible to subclass SessionIDManager and specify that this class should be used instead of the default (<sessionState sessionIDManagerType="..."> in Web.config). The subclass can look for a query parameter containing the existing session id in an override of CreateSessionID(), and return it if found. This essentially allows a page to request being "merged" into an existing session it has knowledge of.
The call to window.open() then simply needs that query parameter specified in its URL.
Haw-Bin
Had a similar problem with PHP5 and IE8. When opening one certain popup window in Javascript with window.open, IE8 lost the session cookie and forced the user to login agan.
Meanwhile, other popup windows worked OK.
The culprit turned out to be an image tag. The template system generates image src = values dynamically and a missing image resulted in an image tag with an empty src clause (
I supect this has something to do with IE interpreting the empty src-tag as an insecure URL and isolating the session in the popup without informing the user.
I was running into a similar issue with using session variables to pass values to a pop-up window. I just ended up writing the values to a persistent cookie and then reading the cookie in the popup window. This may not work with the issue you were having with forms authentication, but if are just using session variables to pass some values to a window in IE8, persistent cookies seems to have worked for me.
edit: see also this thread
You Can Also Use the LocalStoprage method to reset the value in parent window.
localStorage("Key")="Value";//Javascript
Related
What will be the situation if the application is dependent on cookies and user turned off cookies in browser?
Will the application fail to run?
Do developers need to handle it differently when cookies are turned off?
Depends on what your Application should do,
there is always an O-Point e.g. your are online at Facebook
and you start a new window in private mode you will not logged in.
Because the Cookie holds the session (cookie holds serveral informations)
I hope I could help you with it a bit tell me if I missed the topic
The app wont fail to run, but developers have to handle the situation differently when cookies are turned off.
For example, Facebook displays publicities related to your cookie informations. If you were looking for X product on Amazon, it will then display pubs about it.
If cookies are disabled, it would display other pubs, it wouldn't crash.
Here is some puzzling behavior: Following the CakePHP 3 tutorial (approximately), I create a login form and set up AuthComponent to authenticate using the form input. I also set up AuthComponent to authorize. But when I submit the login form, the page appears to reload as if nothing happened. Why?
Additional detail (which turns out to be relevant): I installed CakePHP in the root of the domain, and I am not using mod_rewrite. I followed the instructions in config/app.php to disable mod_rewrite.
I recently ran into this bug and spent quite a bit of time working it out. It presents as a problem with session persistence. Whatever session handler I tried, session data did not persist across page loads. The observable behavior that triggered my investigation was as above; AuthComponent, while it would properly recognize a user and "save" it using setUser(), was unable to "remember" the saved user on the next page load. Put another way, this looks like the login form is failing silently. This behavior turned out to be a symptom of the cookie failing to be loaded on the subsequent page load. AuthComponent (by way of Cake\Network\Session) would write the newly-recognized user to the cookie, but not load the cookie on the next page load, causing it to appear as though my login screen simply re-rendered.
I traced this problem to the 'cookiePath' setting under the Session group in config/app.php. It seems that with the default setting, the cookie's path was being set to "/webroot/". In my setup, I am not using mod_rewrite, and so my URLs look like, e.g., /index.php/users/login. With a path of /webroot/, the cookie was not being recognized and loaded properly. Therefore, the subsequent page load (1) could not read a current session ID, (2) could not find any previously-stored session data (no matter how the session data was stored), (3) could not identify a current user, and (4) punted me back to the login page, sans any Flash error message.
I don't know if this problem goes away if you are using mod_rewrite, and I realize there has been extensive discussion about this on GitHub. I'm not sure who is Officially Right in that thread. However, in case this is helpful to anyone with a similar configuration to me, I resolved this problem by setting 'cookiePath' => '/' in the 'Session' key within config/app.php.
I've just discovered Evercookie project on Github.
Evercookie is a Javascript API that produces extremely persistent cookies in a browser. Its goal is to identify a client even after they've removed standard cookies, Flash cookies (Local Shared Objects or LSOs), and others.
This is accomplished by storing the cookie data as many browser storage mechanisms as possible. If cookie data is removed from any of the storage mechanisms, evercookie aggressively re-creates it in each mechanism as long as one is still intact.
If the LSO mechanism is available, Evercookie may even propagate cookies between different browsers on the same client machine!
I tested it online, on this example page. I clicked "Create evercookie" button, I deleted all browsing data and I refreshed the page. The cookies that were deleted by deleting browsing data returned again there.
Where is the browser security in this thing? Is this secured?
If you want to disable Flash based cookies, use Adobe's "Global Storage Settings" panel here:
http://www.macromedia.com/support/documentation/en/flashplayer/help/settings_manager03.html
Perform all of these Steps:
Uncheck "Allow 3rd Party Flash Content to store data on your computer"
Check "Never ask again" (a non-obvious, but important step)
Click the 2nd to last tab: "Website Storage Settings"
Delete all existing data
Chrome bundles its own Flash plugin on Windows and Mac OS X. The settings and disk storage are separate from the plugin packaged directly by Adobe, so you may need to perform the above steps twice if you use Chrome. On the plus side, the separate storage location prevents Flash from being used to synchronize cookies to or from Chrome and other browsers.
I recommend testing with my personal site:
http://noc.to
The "Zombie Cookie" section can show you exactly how cookies are being restored and help you determine if the above steps (or any tools you use) are working.
In order to create an Evercookie, all you need is:
The ability to run JavaScript (or other active content, like Flash and perhaps Java); and
The ability to access the various client-side locations where copies of the cookie data are stored.
Totally disabling access to all storage mechanisms would render most of them useless; for most of them, their whole reason for being is to allow a script to use them. So the only even remotely feasible option is restricting access by domain. I'm not sure what browsers (if any) allow that kind of granularity, though. Most can allow or block JS as a whole from certain domains, but as for what features a given domain's scripts can use...? I'm not seeing that ability in Chrome 26 or IE 10, at least.
Well, it doesn't seem to work that well.
Created the everCookie
Closed the window
Empty all elements of Firefox cache (just by going to delete recent history anc check everything except site preferences)
Closed the window
Came back to the page
Finally realized it wasn't stored
What is strange is that I dind't explicitely removed Flash cookies in Flash Website Storage Settings panel. Maybe it's integrated into Firefox. Or I may have disabled them.
I think there's several other ways to store cookies and trace you. Facebook is already tracking you all over the web, even when disconnected. Google too (do you use Chrome?). Moreover, with IPv4 addresses, we certainly can find you back (why not just after you've emptied your cache!). We also can find you back while logging back on any site, and make a link with your previous sessions.
I suggest:
Using Firefox, even it's slower than Chrome, it's still more respectful of privacy
Removing the whole Internet cache on window close (sorry you'll have to log again on your preferred sites)
Check third-party cookie options
Use browser addons with care
Check Flash & Silverlight cookie options
Avoid website reputation checking (provided that you can recognize a fishing attempt)
Use private browsing mode when you don't want to share your digital lives
I have a content editor that, when she logs into the Sitecore content editor and clicks an item, nothing happens. The item doesn't load for editing. If she clicks off of the item to another item she's prompted "do you want to save the changes to the item"?
Logging in with another account resolves the issue. Logging in with her account on another PC resolves the issue.
Has anyone ever seen this before? Sitecore is non-functional on this user's PC.
When you say that the item doesn't load for editing, you need to be more specific? Obviously, if she's clicking off the item and getting prompted to save, then the user is able to edit the item. What is it that she can't do?
Also, it depends on what role you have the user set to use, but depending on how you have your site configured, a user can simply click the item, see the fields and enter content in them. There may not be any "edit" queue. Is this not the case? If not, then there's more details that are needed to properly answer your question.
It sounds like a browser / caching issue. I usually try the following.
1. If IE 9 the I try and open a session in private and try again
2. Clear all browser history
3. If that doesn't work try with another browser.
4. If other browser fixes the issue then try to reset the original browser's settings to the defaults.
Last check if you are using a proxy server and try without. This is a long shot.
What version of Sitecore is being used? Older versions using IE9 require compatibility mode to be enabled (this was resolved in later updates of 6.5)
I find the Content Editor most stable in Firefox and IE9 compatibility mode. Chrome has a few finicky issues but generally works.
Some pages in my app allow users to click a hyperlink to launch the external browser via a WebBrowserHelper.
I'm carefully saving the app state in OnNavigatedFrom and restoring it in OnNavigatedTo, but when the user navigates back from the web browser into my app, the app hangs, then crashes.
I've carefully followed the great blog post on the Windows Team Blog, but can also reproduce the bug using the provided code there (just add a WebBrowserTask to one of the button click events on the DetailsPage; or in fact a send SMS task).
Can anyone else confirm this bug, or perhaps point out something special that needs to be done to overcome it?
Whoops! Yes it turns out in most cases you just need to resume the debugger to have the app come back to life.
However in my case there is also a bug in my own code. As usual.