I can't, for the life of me, figure this one out.
This site used to work fine in IE but now it refuses to set cookies. I have tested it in multiple versions on multiple computers and yet still no avail. It behaves normally in all other browsers. The source code hasn't changed, neither has any update been applied to the server.
setcookie() returns TRUE for that matter but I check and no cookie was set.
I checked the time of the server and it is accurate to the second. I have created a sample file with JUST setcookie() and on this domain it doesn't work. All others work properly. Even tried setting the required parameters to all. I have no clue as to what could be wrong.
Version Info:
PHP Version 5.1.6
Apache/2.2.3 (CentOS)
EDIT - SAMPLE CODE
setcookie("session", "e180564a1b6533ec5b0c63e8009d0bc27a90b226", time()+3600);
EDIT 2
It appears as though the client hired another development team who destroyed the DNS, has the A record pointed to another server and is forwarding all traffic via some means to the correct one without changing the URL in the address bar.
This one may have been solved.
Any ideas?
Are you sure that cookies are enabled in Internet Explorer? This is the most common cause in my opinion.
See http://kb.iu.edu/data/ajfh.html for reference.
I've seen IE security settings cause problems with cookies as well. I've never been able to narrow it down to a specific one, but sometimes a P3P header can help - see here for more information: http://articles.sitepoint.com/article/p3p-cookies-ie6/2.
Are the domains/subdomains proper ones? IE will not set a cookie if the domain does not follow the RFC. The most common cause for this is an underscore _ in the subdomain.
Related
How is it possible that perfectly straightforward, conventional, PHP web code that worked perfectly while hosted on Network Solutions​ does not work on GoDaddy​ while both service providers are ostensibly running the same versions of PHP and Linux Apache. The code WORKED on NetSol but not on GoDaddy: Why on one and not on the other ~ that is the question?
None of the previous answers I've found here in Stackoverflow address this particular issue and, in addition, having nonetheless tried those answers just in case, I can attest that they do not resolve this issue.
The issue is simple: 2 well established, built-in, PHP functions will not work on GoDaddy - but do on NetSol: After extensively Googling, and also reviewing Stackoverflow, for an answer - none of which links actually provide an answer to this question - and even after talking to a GoDaddy support tech, I finally admit defeat: I do not understand or know why these functions do not/will not work on GoDaddy but do work perfectly, and as expected/as designed, on Network Solutions.
On Network Solutions, calling if(session_regenerate_id(true)) always produces a boolean true result when appropriate. The exact same code on GoDaddy NEVER produces a true result. Not only that, on NetSol, the session_id does get updated/changed as desired and as expected but not so on GoDaddy.
Likewise, On Network Solutions, calling if(setcookie($name, $value, $expire, $path, $domain, $secure, $httponly)) always produces a boolean true result when appropriate. The exact same code on GoDaddy NEVER produces a true result. Not only that, on NetSol, the related cookie does get created/updated/deleted as desired and as expected but not so on GoDaddy.
I would dearly love to find out why something that works in one service provider environment does not in the other or else I am taking up flower arranging as a career; even mucking out horse stables or cow sheds ~ something I have not done recently :) would be preferable to spending any more time trying to figure this out I am frustrated enough to consider that as an option!!!
Please do not refer me back to links like session_regenerate_id(true) not work or PHP Regenerating session ID on login / out not working. I've tried those suggestions and they do not resolve this issue.
Have you used PHP.ini or other direct INI edits in page to specify an accessible location to store the session data on the server? For example
session.savepath=/home/mysite/tmp/session
in PHP.ini. Try this on both servers to set a clearly defined and clearly accessed folder for session data, with mod 0755 on the folder, just to be sure. I think I'm running on the basis that the session is not working in general, but to clarify (sorry): the session behaviour does work but the session regeneration only does not work?
Are both servers running the same version of PHP?
Have you tried manually setting a name for the session for your website with session_name() ?
Are both servers filesystems / accesses structured in a similar way?
Have you found any error log errors relating to $_SESSION on either server?
Have you tried to view phpinfo() on each server to view differences in settings?
And finally a silly question but:
What did the GoDaddy Support actually say?
I hope with the answers I can update this anwser to give a better - more, er, answering, answer. :)
edit:
Can you confirm you have checked that:
When session.use_trans_sid is enabled, output must be started after session_regenerate_id() call. Otherwise, old session ID is used.
Also, what are the actual values you use in your setcookie call? The setting of the cookie on different servers will probably involve different values on this.
First off, I'm not sure whether this is a problem in Opera 12.01 or not, but the problem only occurs in Opera. I've tested in FF14, Chrome 21, Safari 5 (Windows) and Safari Mac and Webkit browsers on Android and iPhone.
My application runs on the trigger.io forge platform and uses a proxy to route requests from the web application to the service. The proxy simply forwards the requests and cookies along and this works as expected in most of the browsers.
After inspecting the request in dragonfly, I noticed that the server sends the proper headers in the response, but Opera seems to be ignoring setting the values. I'm wondering whether this is due to some misconfigured path value for the cookie. I've attached screenshots of 2 requests in Firefox and Opera.
As you can see in the screens, FF sees the cookie headers and sets them appropriately, but Opera does not.
Firefox Request
Opera request 1 Screen
Opera Request 2 Screen
I haven't included the code from the proxy that does the request forwarding, so please let me know if you need that to gain some insight. On the service end, I'm running PHP and Codeigniter. Please let me know if I need to add any more info here on my environment, thanks.
UPDATE : This issue occurs even in my production environment which does not use a custom TLD. Other sites that use cookies work fine and cookies are enabled.
Double quotes are formally illegal in a cookie value. If you escape them as %22 it will work.
Have you checked if this is an issue with cookie domains ? I'm assuming you're using Javascript to set/read the cookies ? In any case there are 4 cookie domain issues that you might want to check (I know I've had these issue with an old FF version):
1 - check for illegal cookie characters: allowed cookie characters you might not be allowed to use '-' or '=' in the cookie name, and you shouldn't use non-ASCII characters in cookies at all. A base64 encode might deal with this.
2 - check that the domain on which you set your cookie (via javascript code or any other way) is identical to the domain on which the code is executed.
3 - check that the cookie domain is not localhost; see if you can test setting the cookie from a remote domain
4 - if you're using JS to set your cookies, try testing if you can set the cookie with a CGI in your browser to make sure it's not a browser issue. If it works which it should, see if you can read the cookie using JS (as opposed to setting it).
Let me know how this goes in the comments, I've dealt with similar issues a number of times and depending on what you get with these checks, I'm pretty sure I can help you fix the issue.
Have you checked the "leading dot" form of a cookie domain in setcookie. I've been using leading dots for years and only recently noticed my app wont set cookies on opera (chromium et al?) due to the leading dot which is part of a deprecated RFC. In opera, it's not that the leading dot gets ignored but the very setting of the cookie itself. I've removed the leading dot and its working now.
Looking at those Opera screenshots, they seem to be AJAX / XHR requests which are processed within the same second. Is it possible that Javascript is triggering both of those requests "simultaneously", so the response from the "first" is not arriving before the request for the "second" is constructed - and therefore the cookies have not yet been set?
I'm not familiar with the technologies/toolkits you're using, so don't know if these are stock code or part of your custom application.
I've been trying to track down some annoying session issues since my webhost upgrade to PHP 5.3.3 awhile back. I've determined that if there is an active session, calling session_start() from a subdirectory kills the existing session. As an example, I start a session and a user logs in to domain.com/index.php then the user navigates to domain.com/members/ which fires start_session() ... the user's session is lost.
I've dug around for this and can't find anything similar. Is there a PHP configuration that would account for this behavior?
Calling session_start() multiple times with that version of PHP shouldn't cause any problems, however there are other possible causes.
One possible explanation is that the client's browser isn't sending the session id back to the server. You can test this out by comparing the session id that both pages produce. Assuming that you have a controlled environment where you can test this properly, you can use session_id() to get the session.
It might also be that the user is hitting a different webserver. Since (by default) PHP stores sessions to disk, there is no way for multiple servers to share the session information. If this is a shared host, it's probably quite unlikely this is the cause. You can test this out however by using phpinfo(). It should give you enough information to determine if it's the same server or not. For multi-server systems, I'd look at storing sessions in memcache or mysql.
if your sessions works all right within the same directory (it is unclear from your question), there is the only possible reason for such a behavior, a pretty obvious one: "directory" cookie parameter.
It seems it is set to somewhat unusual value, other than default "/" for the session cookie parameter.
You have to check it out.
Anyway, it is almost useless to try ANY session/cookie related problem without an HTTP interchange log.
You have to use some HTTP sniffer, like LiveHTTPHeaders Firefox addon to see what cookie header was sent by the server and which one was returned by client.
Otherwise it's all going to be shooting in the dark.
Okay, as it seems from your yonder comment, the session id remains the same, so, no HTTP issue can be a reason. The issue become a kinda tricky to spot.
Could you please post your test script here?
I've spent quite a long time searching, trying, testing for what looked like the same problem. As google kept sending me here, I think sharing the solution might help others (though I feel strange posting on a 2011 question):
Session variables set in /bar.php were not set in /foo/foobar.php.
It realised that the issue had nothing to do with folder/subfolder when I finally found out that the link in http://www.example.com/bar.php was pointing to http://example.com/foo/foobar.php (missing www).
Correcting the URL in the html link solved the problem. Having no time to dig deeper, what I can figure out is that (in my config) Apache makes no difference and serves pages indifferently with and without www, whereas PHP doesn't share the session between what it considers being two different domains, example.com and www.example.com.
Is there a PHP configuration that would account for this behavior?
Yes, if the storage for the session data differs between those calls, the $_SESSION content will differ as well. The storage can be configured, see http://php.net/manual/en/session.configuration.php for all configuration options you have with sessions.
Next to that if PHP is unable to read the session store, you will get an empty array as well.
I can't tell you if this is the issue with your problem, but probably it's helpful.
BTW, calling session_start() and than having an empty $_SESSION is commonly a sign that a new session has been created. You can verify this if you use cookies for your sessions and you output headers_listDocs:
echo '<pre>', var_dump(headers_list());
If it contains a new cookie for the session, the session has been created with this request.
Lots of good suggestions here. Thanks everyone. I spent a good chunk of the weekend digging into this and wasn't able to directly resolve it. I ended up demonstrating to my webhost that this problem happens on two of his hosted sites and doesn't happen in a default install of PHP. To work around the problem, I ended up moving all of my login and session logic into a single class.
Wanted to share another answer, found in this SO: Session variables not accessible in subdirectory answered by clayRay.
My answer was that I had a custom "php.ini" file saved in the root directory, and moving those directives into ini_set() calls solved it. You could also shove those over to .htaccess if your host allows.
This is a variant of a common php problem that seems to defy solution (and common sense): when a user switches between http and https on my site, php dumps the contents of the session. This would be bad enough, except for the fact that the site works fine when I run it under the domain test.mysite.com. The problem only shows up when I run it under www.mydomain.com, and only on our new server. The code worked just fine on my old machine!
Both servers are running CentOS, with the troublesome one on Rackspace CloudServer.
Any suggestions?
Edit
Just to make something clearer: the session actually gets cleared when going to a secure page. I can't go back to an unsecured page to view the original contents of the session, even though the session id's haven't changed.
Sounds like you've fallen victim to the curse of the dreaded php.ini file. Some cookie parameters are getting set differently.
I would ensure that the php.ini files in development and production are EXACTLY the same, you are running the same version of PHP, ideally the same build.
EDIT: ok, so it's not necessarily a difference in php.ini.
Have a look at the domain you're using for your cookies. If you set a cookie without explicitly setting the domain, it is the current domain only.
If this is www.example.com, users who visit http://example.com/ then are redirected to https://www.example.com/ WILL LOSE THEIR COOKIES.
Why? Because the cookie is being set for the exact domain, and won't be sent by the browser to a different host name.
The same is true if you run the site on multiple names. Be sure that you only run the site on exactly one name. If a user arrives on any other name, redirect them with a permanent redirect to the One True Name, before setting any cookies.
Can you try setting the secure flag to false using this function?
<?php
session_set_cookie_params(0,"/",".mysite.com",false,true);
?>
More info here: http://us2.php.net/manual/en/function.session-get-cookie-params.php
So I have been working on a project for a client on their current web site which has been in existence for quite some time. The version of PHP used is 4.4.7, and I am not in a position to ask them to upgrade. (The system is old and it could break something) This past week I made some changes to my project, everything worked fine cookies set, pages worked. I go to test the site earlier and all of the sudden the cookies no longer work. After 2 hours of troubleshooting I finally just set up a simple test page composed of this:
<?php
setcookie('eventCookie','1', time()+7200,'/','.levijackson.net');
echo $_COOKIE['eventCookie'];
?>
I put this on both their site as well as my own (I changed the .levijackson.net to the appropriate domain)
I did 2 refreshes of the page on both pages and only on mine did it return the cookie. So what could have caused something like this? Is there a certain setting that may have been changed by their admin/host?
I did test and HttpOnly cookies still work, so I am going to switch to them while I troubleshoot.
edit: Almost forgot to mention, it works fine in FF but in Chrome and IE it doesn't work at all. Not sure if this will be useful, but I still think that it is not the browser.
Thanks
Levi
Just a guess-- it could be that their server has auto_prepend_file enabled, and the file that is being auto-prepended outputs something to the client. Once anything is sent to the client, set_cookie() will not work, since cookies have to be set in the page header, which must be sent before anything is sent to the client.
If it's not that, try diff'ing the "PHP Core" section of a phpinfo() dump, looking for any other settings that might somehow affect this.
Edit: Here's something else you can try, if both sites are publicly accessible. Go here: http://web-sniffer.net/. This site will show you the actual HTTP headers which are being returned by the site. Run the test file for both sites, and look to see if there is any difference in the Set-Cookie headers which are returned.