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.
Related
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'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
I am trying to configure a load-balanced environment using Yii 1.1.14 applications, but I seem to be having the problem where Yii does not keep a user logged in when the load balancer uses another node. Most of the time, when logging in, it will ask the user to login twice because it only logs in on one node, and then loads the page on another. Otherwise, it will ask the user to login again half-way through browsing.
The application is using DB sessions and I can see that the expire time is being updated in the database. Even in the case when it asks them to login again straight after they have already logged in, the session expire time is updated in the database. Does Yii do anything server dependent with the sessions?
I've searched around for hours but unable to find much on this topic, and wondering if anyone else has come across such problem.
On the server-side, I am using Nginx with PHP-FPM and Amazon's ELB as the load balancer. The work around (as a last resort) is to use sticky sessions on the load balancer, but then this does not work the best if a node was to go offline and force the user to use an alternative node.
Please let me know if I need to clarify anything better.
The issue was that the base path which was used to generate the application ID, prefixed to the authentication information in the session, did not match on each server. Amazon OpsWorks was deploying the code to the servers using the identical symlinked path, but the real path returned by PHP differed due to versioning and symlinking.
For example, the symlink path on both servers was '/app/current'. However, the actual path on one server was '/app/releases/2014010700' and the other was '/app/releases/2014010701', which was generating a different hash and therefore not working with the session.
Changing the base path to use the symlink path in my configuration file fixed the problem, whereas before it was using dirname() which was returning the real path of the symlinked contents. I also had to remove the realpath() function in setBasePath in the Yii framework.
The modifications I made to the Yii framework are quite specific for my issue, but for anyone else experiencing a similar issue with multiple nodes, I would double check to ensure each node contains the application in the exact same path.
Thank you to the following article: http://www.yiiframework.com/forum/index.php/topic/19574-multi-server-authentication-failure-with-db-sessions
Thought I'd answered this before, but took a bit to find my answer:
Yii session do not work in multi server
Short version: if you have Suhosin enabled, it's quite painful. Turn it off and things work much better. But yes, the answer is you can do ELB load balancing with Yii sessions without needing sticky sessions.
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
I am running a Joomla 1.6 site, which I recently moved to a new server. I moved the site file system using rsync, and I replicated the MySQL database using MySQL utilities. The previous server has running Ubuntu server 10.10 and the new one is Ubuntu Server 11.10. Everything seems to be working correctly, except one thing...
In the site configuration, a user's session is set to expire after 24 hours. On the previous site it had been working correctly. On this new site, I have found that after a user logs in successfully and uses the site for some time, the user is logged out intermittently (randomly?), well before 24 hours, and then upon logging back in to the site (even in the back-end) the site is completely blank. The main menu is not there and there is no content. The logout button still appears, however, and the main banner. If the user logs out and then logs back in, usually all the content appears again like it should, and the site continues to function properly until the next time the session is booted.
Does anybody have any experience with this? Is there a place a can start debugging to find out why the session is ended abruptly? Why can I log in to the site and still not see any content?
I share the same issue. Being logged out, then logging back in and seeing nothing.
It is very random, and will happen 10 times in a row, or never for two weeks.
This happens on a site that's quite complex (plenty of extensions), and has some traffic (5000 hits/day + 100 admin access / day) on J. 1.7
There is obviously something wrong with the session management.
In an attempt to make the site faster we have tweaked the database and moved the session table to memory, and I believe this may be the key aspect here.
Once we had repeated errors happening and clearing the sessions table solved it (until the next day), so I would guess it's connected to the in-memory sessions table.
If your table is in memory, try moving it to disk; if it's not, try emptying it and see if it happens again, and post back! Good luck
More news.
After long debugging the issue was related by an exception in the core which was not properly handled (related to saving an item with a duplicate alias, i.e. saving a second article in the same category with the same title/alias).
For us it was enough to migrate to J 2.5.3 to solve the issue.
Anyway, as a general comment, such behaviour could be related to an error in some Joomla files, which should leave traces in your error_log (else enable error logging).
It took my customer 3 months to understand what they were doing and describe it so finding an error might speed up the diagnostics.