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
Related
Ok this is a weird one. I've just moved the CodeIgniter code to my client's webhost, serverlogic.com. This code has been working on over 40 other servers, but now suddenly I'm running into walls. I'm using DB sessions.
This doesn't work:
$this->session->set_flashdata('contact_message', validation_errors());
$this->session->set_flashdata('first_name', $this->input->post('first_name'));
$this->session->set_flashdata('last_name', $this->input->post('last_name'));
$this->session->set_flashdata('email', $this->input->post('email'));
$this->session->set_flashdata('zip', $this->input->post('zip'));
$this->session->set_flashdata('phone', $this->input->post('phone'));
$this->session->set_flashdata('comments', $this->input->post('comments'));
This works:
$this->session->set_flashdata('contact_message', validation_errors());
$this->session->set_flashdata('first_name', $this->input->post('first_name'));
$this->session->set_flashdata('last_name', $this->input->post('last_name'));
$this->session->set_flashdata('email', $this->input->post('email'));
/*$this->session->set_flashdata('zip', $this->input->post('zip'));
$this->session->set_flashdata('phone', $this->input->post('phone'));
$this->session->set_flashdata('comments', $this->input->post('comments'));*/
As the set_flashdata() method uses cookies to keep track of data, could it be that there is some server limit that is hit once there is too much data stored in the cookies? When investigating the headers on my server it's setting more cookies when compared to this server.
I'm also getting a PHPSESSID cookie from their server, but I don't know where it is coming from. i'm not a server admin and as they are using Nginx I'm totally in the dark on this one.
As the set_flashdata() method uses cookies to keep track of data, could it be that there is some server limit that is hit once there is too much data stored in the cookies? When investigating the headers on my server it's setting more cookies when compared to this server.
You just answered your own question,
As you said flashdata uses cookies to store the data, the fact that it is only this one server means a possibility of two things.
This particular setup is setting more data due to your code (e.g. you might not be storing a particular variable on your other setups which just happens to be tipping this over the edge).
This server is setting more cookies by itself (a possibility with nginx), it could also be an issue with nginx doing some form of internal rewrite on your cookies so a domain issue is stopping the cookies from working properly, but this is less likely.
You said that you get a page cannot be displayed error, my suggestion, look into the server logs to find out if there are any errors. next inspect the cookies using the chrome developer tools or similar, find out if the data looks like it has suddenly been cut off.
Have you tried commenting out each set_flashdata to see if it's one particular statement? Or did you work backwards from comments? Or did you just happen to start with zip?
If you are using DB sessions the structure of your table where the session data is being stored is important. The only thing I can think of is that your columns aren't set up correctly for the types of data and the length of each amount of data being stored.
Maybe double-check the table structure with other tables you have defined on the servers.
If I belong to the no-www camp, cookies I have set in http://example.com would be read by http://sub-domain.example.com,
And regardless of the language I use (perl / asp.net / php / JSP) there is no way I could ever work around this issue because it is a fundamental architecture of HTTP itself, true or false ?
What I'm concerned here is, is there any DNS config that would prevent http://sub-domain.example.com from reading the cookies set in http://example.com ?
I have a domain name http://qweop.com
I have a subdomain at http://sd.qweop.com
Now, the problem is that even though I've not set any cookies on http://sd.qweop.com, when I read the cookies, there are cookies there. They are reading cookies from http://qweop.com.
How do I fix the problem so that the cookies from the main domain would not be read by (a request to) the sub-domain?
I've tried altering the 5th parameter of the php setcookie function but it doesn't seem to do anything. Basically that parameter is like useless. I'm suspecting it's a limitation of the HTTP infrastructure.
DETAILS:
http://qweop.com/set.php (try to use incognito to allow easy cookie removal)
<?php setcookie("testcookie","testvalue",time()+60*60*24*30,"/","qweop.com");?>
cookies set
http://sd.qweop.com/read.php
<?php print_r($_COOKIE); ?>
// No one had set any cookies in http://sd.qweop.com but we can see cookies here! Error!
Answer: Yes
I had better catalog the answer here after 500 hours of google research.
Basically we should always use www if we're planning to use any other sub-domains and we want them cookie-free. This is because there are different browser behaviors with regards to top-level domain cookies.
We can try our best to tell the browser "Hey's set it to just the domain and not to it's sub-domains" but as long as the url is non-www, they won't be nice and behave the way we want them to.
In fact, even if the url is not non-www, they can still do whatever they want to, there is currently no record of any browser that does that (and most likely so too into the future).
I believe you cannot do anything about it. You might try to set the cookie as:
setcookie('some_name', 'some_val', 0, '/', 'yourdomain');
but it will be set to all subdomains of yourdomain even though RFC 2109 says if the cookie is to match the subdomains it should be set with a dot as .yourdomain. All major browsers are sending it to the subdomains. I checked it with IE, FF and Chrome.
Unfortunately, DNS config has absolutely nothing to do with cookies (as long as they belong to the same 2-nd level domain, of course).
You still can have a practical answer if you ask a practical question though.
I have a site I'm deploying and I've hit a problem. I was testing my code in a sub-directory of my clients hosting package and everything seemed fine. However I've moved the folders/files to the site root and now I'm intermittently losing all session data.
I've taken a look with LiveHeaders in Firefox and these cookies are being set:
Cookie: __utma=196298984.443251570.1275554915.1275554915.1275557276.2;
__utmz=196298984.1275554915.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none);
__utmb=196298984.188.10.1275557276; PHPSESSID=3f5a363de3b7ec6084c7fdf90bec78a8;
__utmc=196298984
and
Cookie: __utma=196298984.443251570.1275554915.1275554915.1275557276.2; _utmz=196298984.1275554915.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none);
__utmb=196298984.189.10.1275557276; PHPSESSID=3f5a363de3b7ec6084c7fdf90bec78a8;
__utmc=196298984
I'm by no means an expert on headers so if you need other information, I should be able to get it.
For a session to work, two elements have to both be working:
First, the browser must send the same PHPSESSID cookie with every request. The session ID will change from one session to another, so if you login tomorrow (or later today, or in a different browser, et cetera) you'll get a different ID than you have now, but during a single session the ID should not be changing.
Second, the server must be able to access the same files associated with that ID during every request. By default, PHP stores that information in the /tmp/ directory. If you have access, you could even poke around there and see what's getting stored.
The first issue is easiest to test for. Take a look at what cookies are being sent while the session is working, and then check again after the session stops working and see if the PHPSESSID has changed. The most likely cause for behavior like this would be a poorly set local computer clock, poor timeout settings on the session, et cetera.
The second issue is a bit trickier. If your browser is sending the right cookie with every request, but PHP can't access the file with information about that session, the problem is with the server. You might consider storing your sessions in a database (if you're using one anyway), which is easily done with code in the PHP manual.
A couple of things that come to my mind:
1 : Make sure that if your session is being created on www.abc.com, then all browsing happens on exactly that domain, if some pages are being sent to abc.com instead of www.abc.com, this is likely to cause session/cookie problems.
2 : also make sure that session_start instruction is available on top of ALL pages.
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?
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?