I've mentioned it on here before, but still have the problem, so have added some extra info :)
We have a local intranet site that everyone on the network uses, maybe 5% (or even less) of the users that use the site have problems where the session isn't stored properly.
I've tried defining a path manually and whereas most users sessions are created and remain just fine, on the affected machines it seems that it either forgets the cookies are there, or it can't read them, and then goes on to create a new cookie almost every time you refresh a page.
Things to note are...
happens on both the Zend login screen and our systems, so for once it's not my dodgy code!
it only affects <5% of users
it only happens when using IE
it only happens with Windows XP or Vista - Windows 2000 works fine!
it happens to those users on any XP/Vista machine, so I can use my bosses PC and it's fine, but if he uses mine it doesn't work again...
I've tried messing with the security settings in IE too, changing the cookie security to allow all cookies/sessions, but no luck on that either unfortunately. :(
I've tried nettool but it didn't really help much unfortunately, since it just showed that the new cookies/sessions were being created, but didn't say why.
I've also tried checking the date and times are on the same on the server as they are on the workstation, and yup everything is set fine.
The name of the server is 'gc-hr01' - not sure if that should affect anything like this.
Any help would be amazing, really stuck on this.
Thanks!
The session cookie might get refused because of insufficient validity and/or privacy information. Try to make those as specific as possible, for example:
session_set_cookie_params(0, '/path/to/your/php-application', '.www.example.com', false, true);
I know this is an old thread, but in case anyone else happens upon this, the cause of this problem is likely the hyphen in the machine name. Apparently IE7 won't store cookies for domain names with a - or _ because they technically aren't valid. Certainly would be nice to get an error message instead of silently dropping the cookie, wouldn't it?
Could it be that 5% of the users have user information that, when retrieved from the cookie, disrupts the proper reading/decoding/parsing of the cookie server-side?
Related
Framework: Laravel 5.1
Problem browsers: All versions of IE (inc. Edge)
Problem: When posting a form a cookie is set when the user is send back after submitting the form.
return Response::make($view)->withCookie(cookie('parameters', json_encode($request->except(['_token']))))
This works in ALL browsers, except of course Internet explorer (why does this browser still exists?!)
In internet explorer i get an empty array when i dump the cookie. I've tried a lot. I'm not using iframes, but i did try to use P3P headers without success, i've set IE to the lowest security level possible, also without success. I'm not using suddomains or underscores in the cookiename. I tried it on multiple domains without success, i tried it on apache, nginx, and in my local env. (homestead) it also does not work.
It looks like the cookie isn't set (while in all other browsers it is being set). Unfortunately IE does not have an option or possible add-on to easily check al stored cookies (like all other browsers do). But i`m almost certain the cookie doesn't get stored. This is strange, because laravel's session cookies are stored.
I think i already spent a half a day on this, but cant find any solutions. If i would get payed for all the hours i spend on weird bugs with IE, i would be a very rich man. Will stop bashing IE now, but men, what a horrible browser.
edit: Other things i tried: Timezone checks, date checks, server time etc. All didnt work
Maybe you should try renaming session cookie to a alpha numeric string. It's laravel_session which is causing problem in IE. I remember last month when I deployed my app with session cookie (domain.com) and I got similar token mismatch error in every browser due to . in session name.
I tried to Google and came up with this:
Security patch MS01-055 prevents servers with improper name syntax
from setting cookies names. Domains that use cookies must use only
alphanumeric characters ("-" or ".") in the domain name and the server
name. Internet Explorer blocks cookies from a server if the server
name contains other characters, such as an underscore character ("_").
Because ASP session state and session variables rely on cookies to
function, ASP cannot maintain session state between requests if
cookies cannot be set on the client.
This issue can also be caused by an incorrect name syntax in a host
header.
Source: https://support.microsoft.com/en-us/kb/316112
Q5: IE won’t set a cookie when the hostname/domain contains an
underscore?
A: Correct. Technically, an underscore (like this _ ) is not a DNS
character, and while Windows will let you use an underscore when
naming your machine, it warns you that doing so may cause problems.
One such problem is that WinINET blocks attempts to set cookies on
such domains. See http://support.microsoft.com/kb/316112/en-us
http://blogs.msdn.com/b/ieinternals/archive/2009/08/20/wininet-ie-cookie-internals-faq.aspx
Here is the problem we have been facing for the past few weeks.
1/ Our setup
PHP 5.4 + MySQL
2 dedicated servers, load-balanced
Sessions are replicated between the 2 servers using memcached
3 applications running on these servers :
One custom-developped application, using default php session settings
Another custom-developped application, using different session settings (cookie name, path)
One Wordpress CMS
2/ The problem
The problem occurs on our first application.
Some of our users reported that they sometimes get disconnected after a few minutes (when the session is setup to last 3 hours). It can happen to them several time in the same day, then no disconnection for a few days, but the problem always comes back.
So far the fraction of users impacted is small, but I would like to solve this before it "spreads" to other users.
The problem seems to occur in different places of the application, though we have identified 3 scenarii where most of the errors occur :
Some involve submitting a form ($_SESSION variable is modified)
Other simply involve opening a popup page, with no modification of the session data
We have tried to reproduce the different scenarii described by the users : sometimes we have been able to, but most of the time we don't have any problem, which makes it hard to debug.
Other notes :
The problem is recent, this application had been running for years without any problem.
It doesn't seem to be related to our server load, because the problem still occured during the summer break when our trafic was low
It only affects one session/users at a time: all the other users logged in at the same time don't experience this problem
The problem occured on all the different browsers (IE, Firefox, Chrome)
3/ Technical analysis
When a disconnect occurs, the user is redirected to a page "Your session has expired or you don't have the right to view". When this page is loaded, we get a technical email with a dump of the $_SESSION variable.
When a session expires the normal way, the email we get shows that the $_SESSION variable is empty (normal behavior).
When an unexpected disconnect occurs, what is interesting is that the $_SESSION is not entirely empty : out of the ~20 elements the array contained, only one is left (always the same).
So this would mean the session is not expired, but not enough data is left to "identify" the user, hence the "no rights" page displayed. As a confirmation when this occurs, we can check in memcached that this session still holds some data.
These are the potential problem causes we have identified so far, and what we have done to rule them out :
Memcached indicates between 70 et 80% freespace, so we don't think it is the problem.
We removed Memcached and went back to using a NFS shared directory for session files: the problem actually got worse. This would point to an applicative bug, because NFS being slower to write data, session loss would occur more often.
We have browsed all the different forums (including SO) talking about PHP session data loss, and reviewed our code accordingly. The code base is big, but we have used automated tools and scripts to avoid missing a file.
session_start() is called at the beginning of each page.
exit() is called after each header("Location...")
register_globals is Off
We have tested the possible interractions between our 2 other applications and the problematic one, though they don't share any code, database or session handling. Nothing identified there.
We have analyzed our access logs around the times of the disconnections, to check for behavior patterns : no luck here either.
So we have no idea what causes this problem, as it seems to occur randomly, so my questions are :
The problem could come from our code: did we miss anything to check ? This solutions seems unlikely as the code works most of the time for all our users, but I am still considering it.
The problem could come from another application/process that would "empty" part of the session variable array. We have also reviewed the code from the other applications, but didn't find anything that could cause this.
And if another process is doing this, why would it only empty some sessions and not all of them ?
Thanks for your help.
I don't think you'll get a definitive answer to your question. There are too many probable causes and you haven't shown any code.
Still, my guess is that you have memcached.sess_locking turned Off, or if you have a custom session implementation - that it doesn't implement locking at all.
Eventually, this leads to a race condition between two simultaneous HTTP requests.
My guess is based on the often seen bad advice to turn off locks or free them as soon as possible, in order to achieve higher performance.
If this problem "suddenly" occurred, check what has changed. Did you do any work on the application? If so check committed code (you talked about automated tools so I expect there to be a repository which would allow for accurate finding of code changes).
Did you change anything on the server? Like upgrade software, upgrade/change hardware, make changes to the other two applications ?
One thing that popped to mind, did you check the drives you use for caching? It could be a corrupted part of the file system. Which would explain the random user part.
I couple of things I always to is:
Try to determine the moment of first occurrence as accurate as possible. At my work this occasionally triggers someone saying "oh yeah that might have to do with when I changed/updated/created this or that" so this might help. On the other hand it can sometimes takes days, weeks or more before something gets noticed so start expanding that time-frame if nothing comes up.
You have already a couple of scenario, find the common factor in these. If they don't share any code, stop looking there. If they DO share code search there. Of course sharing (part of) it here might allow us to help you search.
Do an organised search. I usually do the main application check when I am the one working most on the application (or even better when I created it). A colleague will check surrounding applications that might have influence on it. In your case those 2 other applications. Finally our sysadmin will check for newly installed or updated software on the server(s) and he will also check with our network guys if anything changed hardware wise or network related (for other people this could be the hosting provider).
It could be as simple as a WordPress plugin that uses sessions and calls either session_name() or session_id() with a different value, overlapping your custom applications with default session settings.
Since WordPress itself does not use sessions, plugins are often written from the perspective of having free rein with sessions. I just did a search on a WordPress test site and found sessions used in a gallery plugin, a plugin for putting a background image on the page, a shopping cart plugin, and a plugin I was writing that needed to carry an uploaded file from one admin page to another.
I have a site which does a few ajax calls on page load. For some reason, CodeIgnitor is inserting 4 sessions (I'm assuming one for each ajax call) as you load the page. I'm storing the sessions in the database.
I'm pretty sure there should only be one session per browser. Firefox seems to generate only one; other browsers seem to create a whole bunch of sessions. Multiple sessions for the same user are giving me some serious authentication problems.
Why is this happening? How can I stop it?
I know the discussion took place while ago, but somebody might find this useful.
By now I've used CI session without storing its data in database. Today I decided to give it a try and immediately run across the same problem: CI was generating new session in every page load.
I checked my server time, timezone, my cookie etc. - everything I could find as a tip on forums - with no result. Then decided to debug the CI Session class myself.
Long story short, it turned out that my user_agent field in my session table was too small - VARCHAR 50 - which cuts the original user_agent string - hence CI doesn't find my session and generates onother one. I just increased the user_agent field size to 200 and everything works like a charm.
I forgot to mention that I use Mac OS X Lion.
Again, hope this will help somebody.
Check the date / time on your client OS, and on your server.
I know its too late, but maybe someone finds this page while looking for the answer...
I think it happens because CI sets an expiration time on the cookie containing the session id and if the time difference between the server and client is higher than the expiration time the cookie gets old and the server will generate a new session for the client on every request. Never took the time to figure out the exact mechanism, but happened to me several times, and this fix always worked.
I've found this topic with same problem: on every page CI generates new session. Possible solution: remove underscored from site name ( NOT "my_test_site.com", but "my-test-site.com"). At least, this helped in my situation.
Check your config.php file and make sure the cookie options are properly filled out. If they are not it cant track the user and it will gen a new session on every page load.
Check the date / time on your client OS, and on your server.
I had the same situation and confirm the solution as a fix
$config['cookie_domain'] = "example.com";
Use your domain name in this snippet.
The problem is that I have a PHP script (A) that does signup, authorize Twitter, then the twitter calls back to a return PHP script (B).
In script (A), I set some $_SESSION variables, and in script (B) I will get it. Very straight foward.
I have tested it on my computersss, and it all works. I can see the session variables in script (B) set by script(A). so as my friends.
However, the most important thing is, my boss' computer cannot see it! that's the worst. he also tried on his computersss, still didn't work at his end.
I even reboot and restart the server, but still, situation remains the same.
So, my question is, is there any kind of restriction that the server cannot set the session on a computer? or,.. in which situation, the server will fail to set the session?
Server: Apache 2.2.3. Using Plesk
PHP: 5.2.5
Maybe a stupid question, but anyway... does your boss block cookies on his computer?
If that were the case and for some reason PHP was set up to not 'fall back' to passing the session ID via the query string (or the redirect stripped it somehow), that may be a problem.
The session id is different on different computers because that's the idea behind sessions. You assign a number to each visitor (the session id) and by that number you can identify users and store information in each users $_SESSION array. This array is available only to that single session/user.
If you want something to store data for all visitors of your site, you might want to use a database or a serverside cache.
Since it’s the session that fails, check that the client uses the same session on every request and not a new one. Check if the session ID is carried along properly. If you’re using a session cookie, check its validity settings and see if the session cookie is accepted by the client. See PHP Session/Cookie problems with Windows XP, Vista, IE and certain users.
We have a local intranet site that everyone on the network uses. Maybe 5% (or even less) of the users that use the site have problems where the session isn't stored properly.
I've tried defining a path manually (C:/Coookieess) and checking to see what's going on. Whereas most users' sessions are created and remain just fine, on the affected machines it seems that it either forgets the cookies are there or it can't read them, and then goes on to create a new cookie almost every time a page is refreshed.
Things to note are...
it only affects <5% of users
it only happens when using IE
it happens to those users regardless of what machine theyre using
it only happens with Windows XP or Vista - Windows 2000 works fine!
I've tried messing with the security settings in IE too, changing the cookie security to allow all cookies/sessions, but no luck on that either unfortunately :(
Any help would be amazing. I'm really stuck on this.
Thanks!
Just a random idea, and probably not relevant, but worth mentioning just in case - are the date and times set correctly on the computers you are having problems with?
I had the exact same issue and found that adding the P3P header before starting the session corrected it.
header('P3P: CP="IDC DSP COR CURa ADMa OUR IND PHY ONL COM STA"');
session_start();
One other thing you might want to check: are they using a proxy of any sort?
One of the PHP projects I worked on seemed to have troubles with sessions when the app was run on the intranet. Turned out that all of the IE installations had been set up to run through the corporate proxy which seemed to screw up every now and again...
A new cookie can get created when the site doesn't perceive one to be present or passed along from the previous request...
Is there anything about the site, your network or your clients that is causing the cookie hash to not be propagated between requests?
Use an HTTP analyzer (fiddler, nettool) to find out.
Not really got enough info to go on, but one thing that might be happening is that if you're storing the session in a cookie, you might have ended up with a cookie too large for IE to handle.
The definition of "Too Large" varies from browser to browser and OS to OS, though.
any chance your internal domain has an underscore in it? i.e. http://dev_server.example.net
Usage of underscores as DNS characters is kind of hazy. FF/Safari will work just fine, but IE will fail to set a cookie if it comes from a domain with an underscore
Most public registrars will prevent you from using bad characters, but internally there's nothing stopping you.
We came across an issue a fair while ago that would appear to be the same as this - sporadic appearance, only affecting older IE users.
At the time any resources or commentary was quite hazy, so we were never fully able to diagnose the issue - the closest information we found was to do with IE not playing nice with g-zipped data.
Anyway - solution we found that fixed our issue -
Manually set a content-type header through PHP, while removing the HTML declaration
header ("content-type: text/html; charset=utf-8");
Set your site to send a P3P (compact security policy) header.
See http://www.sitepoint.com/article/p3p-cookies-ie6/2/
Could it be that 5% of the users have user information that, when retrieved from the cookie, disrupts the proper reading/decoding/parsing of the cookie server-side?