I am in the process of moving away from Apache in favor of nginx due to the lower resource consumption. I have set up an Ubuntu Server box with the LEMP stack installed. After moving all my applications over (3 CakePHP 2.0.5 apps, 1 Wordpress install), everything seems to be working perfectly except for one thing - Cake's cookies suddenly disappear when the browser is closed.
I have created a very simple test PHP page to test if cookies are working at all and they are in fact working, just not in Cake. Wordpress is also not having any troubles remembering me when I close my browser.
Using the Chrome developer tools, I have inspected to see if the cookie is being set at all, and it is as you can see below:
The expiry date is even set a month into the future as well, so I don't understand why they don't live past browser close. As soon as I fire my browser up and navigate to my app, the cookie is now gone:
One thing I did notice is that with my app running on Apache, the CAKEPHP cookie you see above above has the same value before and after close. However on the nginx server, that cookie has a different value everytime I close and re-open my browser.
I thought this might have to do with sessions, so I checked my session settings in core.php and it's set to let PHP do the session handling:
Configure::write('Session', array(
'defaults' => 'php'
));
I've checked my /tmp directory and session files are being created. I tried changing the session handler to cake so that Cake would store sessions in its app/tmp/sessions directory, and while the sessions would successfully get created in this directory my cookies are still lost on browser close.
Has anybody experienced this behavior between nginx and Cake before, or have any ideas as to why this might be happening?
The problem is related to encrypted cookies and the Suhosin patch. Apparently Suhosin ignores any mt_srand() and srand() calls you make and initializes the randomizer itself [see here]. Because Cake relies on these functions, it was interfering with my encrypted cookies. To fix it, I added these two lines to my php.ini file and rebooted the server (note that simply restarting nginx didn't work):
suhosin.srand.ignore = Off
suhosin.mt_srand.ignore = Off
Related
I'm pulling my hair out over this one.
I have implemented a Symfony session handler using DynamoDB and the AWS PHP SDK: http://docs.aws.amazon.com/aws-sdk-php/guide/latest/feature-dynamodb-session-handler.html
The session handler appears to be working completely fine on my local machine, I can see the session is created correctly in Dynamo, then when I login a new session is created and the data is migrated to it as expected. All good here.
The problem is, when I push this up to my staging or production servers on AWS, something is going wrong when the session is migrated. I go to my login page and I can see the session has been created as expected, then when I login, a new session is created but the data is NOT migrated to it, causing it to dump me back to the login page.
I've spent the last two days digging around trying to work out where it's going wrong, but I can't figure it out.
I've tried every suggestion in this bug thread but none of them worked, so I'm assuming I may be dealing with a separate issue: https://github.com/symfony/symfony/issues/6417
I've also tried using the pessimistic locking_strategy which does not seem to make any difference.
The staging and production servers have the exact same config as my local setup, minus xDebug.
I've put the staging server into dev mode with debugging enabled to try and find the issue in the profiler but I can't see anything of interest in there, the requests are as follows:
GET domain.com/login (session a)
POST domain.com/login_check (session a)
GET domain.com (session b)
GET domain.com/login (session b)
The pattern above keeps on repeating.
Any direction on how to debug this would be appreciated, I'm not even sure where to look, especially seeing as I can't reproduce on my local machine with xDebug.
This turned out to be a problem with the PHP jsonc extension where json_decode was breaking if there were null bytes (a serialized protected method has null bytes). It has been fixed since version 1.3.3.
http://pecl.php.net/package-changelog.php?package=jsonc&release=1.3.5
We have a Laravel project that uses default Auth module for login, but on some computers, users won't stay logged for long. Sometimes the session is lost right after login, so even if it logs successful login attempt, next refresh doesn't get authenticated.
We have tried removing redirect after login as well as various session storages (namely 'file' and 'cookies'), but on some computers (no matter which browser), the problem never occurs while on others it persists.
Possible cause is that sometimes every instance of the same request gets new session, this behavior is random as far as we were able to find out.
The only way to replicate the problem was to switch Laravel session storage to cookies, send a few requests, switch it back to file, afterwards sessions tend to get lost until a cookie set by laravel for session storage with random-looking name and content size a bit over 1kb is manually removed.
We are using Laravel 4.1 and native PHP server (php artisan serve)
From what I've googled so far, neither renaming primary key in Users to 'id' nor removing every redirect helped.
The problem persists even is the whole page contains nothing but /singin/ route and Auth::check() in a template.
Tested browsers are Opera/Chrome/Firefox on OS X 10.5.8 and 10.9, which don't work and Ubuntu 13.10 and another 10.9 OS X that always work.
Could this be a bug in the webserver we are using for development? Has anyone else seen this happening?
Thanks for eveny advice
Switching from Artisan serve (builtin PHP webserver) to Apache solved the problem, experiments suggest that the cause of the problem is a bug in PHP's webserver which prevents it from accepting too long cookie headers.
I'm having problems with PHP sessions that only occur on my testing server (everything works fine on my localhost). I'm developing a custom Wordpress theme, based on Roots. My localhost is OS X (PHP 5.4.4) and the testing server is Ubuntu (5.3.10-1ubuntu3.8).
The problems include:
New sessions created each time I refresh the page (which I can see by rendering session_id() in the footer and checking /var/lib/php5/session)
Functions called through an AJAX request unable to access the correct session, even though session_name() and session_start() are called before they try
Other details:
I'm trying to save variables into a named session, so each time I call session_start() I'm currently doing it like this:
session_name('my_session'); //Not sure if this line strictly required
if (!session_id()) {
session_name('my_session');
session_start();
}
The above is first called in a function init_sessions, hooked into Wordpress like this: add_action('init', 'init_sessions');, then also used in the other files that need access to session variables (e.g. those requested via AJAX).
On localhost, I can see the session file created in /Applications/MAMP/tmp/php and also see a session appear under the Cookies tab in Firebug. However on my testing server, although (too many) session files are created in /var/lib/php5/session, I don't see the session appear in Firebug.
Running phpinfo() doesn't show any significant difference between the PHP directives on my localhost and those on my testing server.
The testing server is really two (Rackspace) servers with a load balancer, but I don't think this is an issue as session persistence is set up.
The testing server is set up as a subdomain e.g. test.my-domain.com.
I've got PHP error reporting turned on but haven't noticed any.
I've deactivated all other Wordpress plugins.
I'm sure it's more likely to be a problem with my script than Rackspace's set-up, but I'm a bit stumped at the moment. I'm particularly curious about why I can see session files created on the testing server in /var/lib/php5/session, but don't see them appear in Firebug's Cookies tab.
Any ideas very welcome. Thanks!
Ok - think I've identified what's going on (though not resolved it yet). It looks as though the problem is down to Varnish. When a user is logged-in, the session functions perfectly. Thanks to everyone that suggested a fix.
Im having a problem where we run an upgrade for our web application.
After the upgrade script completes and access the web app via the browser, we get file not found errors on require_once() because we shifted some files around and PHP still has the old directory structure cached.
If we have the default 120 seconds for the realpath_cache_ttl to expire, then everything resolves itself, but this is not acceptable for obvious reasons.
So I tried using clearstatcache with limited success. I created a separate file (clearstatcache.php) that only calls this function (this is a one line file), and placed a call to it in our install script via curl:
<?php
clearstatcache(true);
This does not seem to work, however if I call this file via the browser it immediately begins to work.
I'm running PHP version 5.3
I started looking at the request header differences between my browser and curl, and the only thing I can see that might matter is the PHPSESSID cookie.
So my question is, does the current PHPSESSID matter (I don't think it should). Am I doing something wrong with my curl script? I am using
curl -L http://localhost/clearstatcache.php
EDIT: Upon further research, I've decided this probably has something to do with multiple apache processes running. clearstatcache will only clear the cache of the current apache process - when the browser is making a request a different apache process serves the request, and this process still has the old cache.
Given that the cache is part of the Apache child process thanks to mod_php, your solution here is probably going to be restarting the Apache server.
If you were using FastCGI (under Apache or another web server), the solution would probably be restarting whatever process manager you were using.
This step should probably become part of your standard rollout plan. Keep in mind that there may be other caches that you might also need to clear.
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.