Basically Session is not working. Session is getting generated and getting stored in the proper folder of the server, but not getting stored in the browser as the usual PHPSESSID cookie. The phpinfo() shows that the Set-Cookie headers are being sent, but Set-Cookie headers are missing in the response that the browser gets. Please check the below screenshots:
Set-Cookie headers present from the server side:
Set-Cookie headers missing in the response the browser gets:
Another info is, if I use javascript to set cookie then it works and shows up in the browser's developer tool.
Everything regarding session is ok, just that the cookie it tries to set on the browser seems to be not setting.
Answering the cause and fix as it may help someone in future and save many hours:
This error happened in a site previously built by someone else. This error seemed quite unusual and I thought the problem is most probably with Apache. I removed Apache and reinstalled to no effect. Then I installed Nginx to see if the problem is with the Web Server software or the Server itself. And I found that Session is working fine in Nginx. So the problem was definitely with Apache somewhere.
As I checked the files found that in the .htaccess file somewhere down below Cookie was unset!!
Header unset Cookie
Header unset Set-Cookie
Never thought someone would have put that! But anyway, removing the above fixed the problem.
Encountered the same behavior with a service provider of mine. Turned out to be a caching problem on their side (varnish cache).
Luckily I was able to disable Varnish-Cache via the provided admin-backend. After that, the Set-Cookie headers were present in the client response.
Related
I am working in a Php application and I have a problem regarding session management.
Whenever I request an an asset (by requesting a file file an extension) that isn't there, I correctly receive a 404 response, but a new session cookie is set. Hence the next time I make a request I am logged out.
The new cookie is set when the call to session_start() is made. It seems that Php is not able to understand the fact that there is already a session cookie present in the HTTP request and therefore it generates a new one.
To make everything more interesting, this happens only in our production environment, where we have Zend Server with Php 5.4.23. The problem does not manifest itself locally where we have just Php 5.4.16.
Do you have any suggestion on how I could solve or investigate futher this issue?
Somehow, when calling another script (all other scripts than index.php), all my CMS authorisation data gets deleted. The login boolean and username consists. This only appears using Chrome/Chromium.
The chrome developer tools don't show any errors, only 200 OK and 304 Not modified.
This is really annoying since I've changed to Chromium for Firefox being to ressource-heavy.
Any solutions?
Its going to be really hard to debug without any code or anything. When you say session data I assume you are referring to your php session. This has nothing to do with the browser. Are you making sure you aren't changing the domain/subdomain while browsing at all (which will cause you to lose your session). You can check your php.ini session settings but that shouldn't matter if it is working on other browser.
I'm guessing this is occuring because your session isn't getting started properly OR the session data is getting cleared somehow in your code.
Now it appears in Fx too. The problem: The hoster updated to PHP5 and there register_globals was set to On again.
This morning my local php starts behaving strangely: the session ID changes on each request (making sessions unusable).
The code:
<?php
session_start();
The same page is available through "localhost" and "test" which is a /etc/hosts entry for localhost.
Requesting this same file on "localhost": the PHPSESSID cookie stays the same; on "test" it changes on every request.
Absolutely nothing changed in my code (no BOM or buggy code) or in Apache's config. I may have updated PHP (5.4.4), but reverting to the previous version (5.4.1) showed the same behavior. The same code running on a remote server (php 5.3) has been running ok for ages.
It's probably a bug in PHP :( but before reporting, I want to be sure I didn't overlook anything.
Any idea?
Thanks for your amazingly fast answer.
In fact the browser works fine, everything is working fine, even PHP.
I just forgot I added a .htaccess clearing all cookies to upload to a CDN. The only thing I didn't check was the .htaccess.
I feel stupid (and tired).
Thanks again.
Install some software watching HTTP headers like
Live HTTP Headers Firefox addon https://addons.mozilla.org/en-us/firefox/addon/live-http-headers/
WireShark sniffer http://www.wireshark.org/
and check whether
Server sends the cookies as it should
Browser sends them back.
Probably the Cookie header contains settings which make Browser not to send it back, and therefore server generates a new cookie (new session) for every request.
Especially check the path setting of the cookie you send.
Also, it might be some new policy in browser, or a security plugin, or maybe antivirus... try different browser, or bare curl program, and disable web shield of your antivirus if applicable.
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.
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.