I have a few CakePHP 2.5.1 websites running on a production LAMP environment with PHP 5.3.29 and MySQL 5.6 (I know, it's old stuff). They use Auth to protect the access to them to only registered users. These websites have had no issues for years.
Recently we started getting complains from users that they are being kicked out of those sites when seemingly they shouldn't be, it even happened to myself once. I'm talking getting the typical message that we display when someone tries to access a protected page once their session expires and they get taken to the login page. Only that those sessions are expiring quicker than they should. We use database sessions for these sites, here's the config:
Configure::write('Session', array(
'defaults' => 'database',
'handler' => array('model' => 'cake_sessions'),
'timeout' => 60
));
Configure::write('Security.level', 'low');
The weirdest thing is that after getting kicked out, if you log in again and try to access a page that you had not accessed in your previous session, you get kicked out again to the login page. But if you access a page that you had accessed before getting kicked out in the previous session, then you can access it no problem. I presume this might be related to caching but I had never seen something like this happen in these sites before, so I thought I'd mention it just in case.
The code of those sites has not changed in years. The only thing that's changed is that the server where those websites are located had some PHP configuration changed where they enabled PHP-FPM, and it does seem like these issues started around the same time, but I don't know how to make a connection between that and the sessions. Also I don't think we can have that disabled.
I've been doing some troubleshooting, printing session variables while using these sites, looking at the database table that handles sessions, verifying session IDs, timeouts, cookies, etc and everything seems OK as far as I can tell. Sessions get automatically refreshed when I navigate to other pages, they show the correct duration, Cakephp cookies show correct session IDs, etc. I have not managed to replicate the issue or found anything wrong in the code, database, cookies, or PHP session. But maybe I'm not looking in the right places.
So in reality I have 2 questions:
Does anyone know what might be going on here with the sessions? What can cause a premature end of a session?
Can anyone suggest a way for me to troubleshoot this? Replicate the issue somehow?
Related
Sounds like a basic question, but after hours of research I still have nothing to solve the problem.
I'd like a simple thing: keep users logged in on my website for longer than 24 minutes.
My site runs on an apache server and shared hosting, I do not have access to edit the php.ini file.
Messing around with
(session.gc_maxlifetime)
did not work.
I'm looking for a cookie-based solution at this point - a cookie that is stored on the client side, and is deleted at logout.
So PHP would not destroy the session despite of inactivity if this cookie is present.
Is this possible?
(I'm running a site with long articles, so users may be considered 'inactive' by the server and be logged out when they click for the next article. That's what is happening now.)
I got a really strange problem in my PHP webapp.
If I log in, everything works fine for the duration of my session.
If I come in the next day, my webapp returns me to the Login page (as I expect).
The problem is that once I log in, parts of my site work and parts don't. The parts that don't return strange error messages and then I'm logged out and need to log back in. The strange thing is that some days some parts don't work and other days other parts don't work. If I delete all cookie values I can see, that doesn't solve the problem. The problem is only solved by deleting the entire cookie itself and then logging in again.
I've turned off garbage collection (because on Ubuntu there is supposedly a cron job which does it automatically even though I can't see it) but the issue was occurring before that.
So in terms of simplicity my intention is two-fold:
- To add code to my Login page to delete the cookie entirely (assuming I can do that from PHP)
- To move session storage from my webserver to my MySQL DB (because I'm in my dev environment but preparing to build my test environment which will be a cluster of webservers, not just one)
My questions are:
- Is there any way to ensure session values die reliably and gracefully rather than lingering and wreaking havoc?
- Is it possible to delete an entire cookie from PHP code, rather than just cookie values?
Many thanks.
After being a constant problem for a while, this issue has gone away. I've actually determined the cause and so I thought I'd post a quick update. Basically I had three sites I was accessing on my domain, my own webapp, a CMS Admin page and another admin tool. I've determined that the session cookies between my webapp and CMS admin were interfering with each other. If I use different browsers to access the different sites, the problem doesn't reoccur. It was driving me up the wall. Thanks to those who posted suggestions/responses. I appreciate it. I'll mark this as closed.
I am using Apache, PHP 5.4 and Cakephp 2.4. recently I am getting random issues with my session.
My queries are based on variables stored in the session and once every 10-15 pages I get a critical error saying that the mysql query failed because it cannot find the field in the database. This field name is stored in the session that's why I suspect it being an issue with my session settings. Moreover, when I get an error and refresh the page 2 or 3 times it finally loads and the session somehow "restores"
It is an e-commerce application and shopping cart is saved in the session. Even if an item is in the shopping cart, I get that error and refresh the page, shopping cart is still saved fine so the session is not completely lost. It seems like it almost disappears for few seconds.
My cake is set up like:
Configure::write('Session', array(
'defaults' => 'php'
));
In my php.ini I already changed
session.save_handler = memcache
to
session.save_handler = files
But it didnt help. I also get that issue when I put a link directly in my url and there is no redirect to it, so it is not an issue with redirects losing a session that was already discussed on this forum before.
Any ideas where else I should look?
I had a similar problem many years ago whereby I was randomly losing session variables. It turned out that my ISP, for reasons related to load balancing, had a PHP instance running on multiple servers. At the beginning of the session the Session Variables would be saved on only one of the servers. If a request came from the browser that was directed to a different server the Session variables would not be found.
I got around the problem by placing the session_save_path('/tmp') command at the beginning of every script and then immediately running the session_start() command. I create the 'tmp' folder in my private public_html space. This solved the problem.
This was in my pre-Cake days so I haven't thought about how to solve this problem in a Cake environment but hopefully it gives you somewhere to look.
So it turned out the reason was recently installed APM. Thank you for all the support
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.
Totally confused by this one...
We have a WAMPServer installation set up, running a number of virtual hosts from various document roots.
Just recently, one particular domain has started hanging the server. We traced it down to session_start(). If we comment it out, there are no problems (except, of course, for the fact that we can't do anything with the session). With it uncommented, it will hang the page load and, with enough reloads, will hang the entire server.
All of the other sites still work perfectly with their sessions. As far as I know, there is nothing different with the way sessions are being worked with. I am looking further into it (in case someone changed something) but right now I'm hoping for some direction :)
So, any thoughts?
So, I'm guessing that it's an application layer problem because the other sites' sessions are working properly. However, this assumes that they have their sessions configured the same way - save yourself some time by double checking that your site isn't doing some "unique" in its configuration compared to the other sites.
I would next examine the other session related code that is running in your application. It could be that by calling session_start() you're putting your application into a state where it will run other code. For example, maybe there's a block of code that says "only run this function if this session variable is set" and by starting the session you're exposing that variable, where it wouldn't have been exposed and therefore not run the offending function if the session wasn't started.
Good luck.
My first guess would be file permissions if you are using file based sessions. If you are using database sessions, then I would check to make sure a table isn't corrupt. Also, is it Apache, PHP or something else that's locked up?
It's possible that you hit a bug in your underlying infrastructure that you won't be able to resolve. You should at least clear all existing sessions before moving forward with trying to diagnose this.