I am using the helper Sentry::authenticateAndRemember($credentials); to authenticate the user, but after a while (a few days) I get disconnected. The session driver used is the database one.
I investigated the problem and tried to understand how Sentry remembers the authentication of a user.
First, in the sessions table, does anyone know what the payload represents ? I have checked the created cookies and I don't understand why but the expiration date is set for a month later (whereas in the source code it looks like it is set 5 years later).
Also, I have tried to log the user in without remembering him (Sentry::authenticate($credentials, false);) and I get the exact same cookie created, so I don't get disconnected when exiting my browser.
Does anyone have any clue explaining anything that I said ?
I found the solution of my problem, in php.ini the variable session.gc_maxlifetime was set to 1440. This setting specifies the number of seconds after which data will be seen as 'garbage', so after 24 minutes my session was invalidated.
After setting it to 2592000 (30 days) the issue was solved, I hope this will help someone.
In Sentry2 with Laravel 4.1 the Cookie expiration date is in vendor>caralyst>sentry>tests>CICookiesTest.php line 61.
The default being just 1440 seconds, so pretty easy to make that stick for a good bit longer.
Related
I have a bug with storing sessions in memcache.
The bug is reproduced, if I log in and try to open around 25 different pages at the same time (different tabs). Sometimes my user gets logged out. The funny thing is that the session is kept, but security context is removed. And even funnier thing is that this security context is restored (probably with other request). And the funniest thing is that if I set default filesystem session storage - everything works as expected.
Sessions are stored on Amazon Elasticache.
If I check my user session on Amazon during those requests - there happens something like this:
Request 1 - My session has sf2_ attributes key and _security_main key
Request 2 - My session has sf2_ attributes key and _security_main key
Request 3 - My session has only sf2_ key
Request 4 - My session has sf2_ attributes key and _security_main key AGAIN
I believe it has something to do with the concurrency.
I've tried lot different things, but I am out of ideas currently. Any tips are much appreciated!
Technical info
Symfony version 2.1.0-DEV
security.yml
Please, let me know if you need more details.
The problem was caused by the different time, configured for php script execution time and memcache session lock. I had 60 seconds for php and 15 seconds for memcache.session_lock
So, what happened under the hood:
Script A starts, locks session, takes up to 60 seconds
Script B starts, waits for session to be unlocked
After 15 seconds of Script A execution, memcache unlocks session.
Script B intrudes in the flow and "corrupts" the session
So I have increased memcache.session_lock time to match php execution time - and the problem had gone.
Symfony 2.1 is End of Maintenance. This means no bug fixes anymore, only security fixes until End of Life in 11/2013.
You should update to Symfony 2.3 LTS, which has a maintenance period of 36 months. Maybe this is already fixed. If not, raise an issue in the project.
Btw. you can try the memcached handler instead of memcache. Mentioned in #8407
I have built an app in CakePHP that allows a user to login and do some stuff, it keeps the user logged in for about 24 hours I think by default. And this is handled by a session/cookie as a cookie also gets created...
1.) So what would a remember me bring to the party? As all that would do is create ANOTHER cookie that sets a timeout and keeps the user logged in... But this functionality exists in every single app by default with the session right? But I've seen lots of sites doing this but I don't get why as the session is doing this out of the box :/
2.) Also how come sessions expire even if a user continues to use a website? e.g. if I set it to be 1 minute but refresh every 30 seconds it will still expire... but I kept the site active before it could expire so how could it still did expire? This is annoying as I have a expiration for an app of 1 hour but even when the client is using the site it expires after 1 hour regardless of activity.
Would be great if someone could answer these 2 questions.
UPDATE: I've created a bounty on this in the hope of getting a CakePHP expert to help fix this problem. The issue is that the Sessions expire after the timeout REGARDLESS of user interaction. What I want to do is say I have a session lasting 5 minutes, and the user causes a postback every 30 seconds, then that session will still be around after the 5 minutes. This is not the case at the moment...
Configure::write('Session', array(
'start' => true,
'defaults' => 'php',
'timeout' => 1,
'cookieTimeout' => 1,
'autoRegenerate' => true
));
What it would bring is that if the user closes its browser and restarts it, it would still log in automatically. This is not the case with a session cookie, since such a cookie is deleted as soon as the browser is closed.
Maybe the page you went to every 30 seconds didn't start the session. In that case, the session mechanism is not used, and the expiration date of the session is not reset to now + 1 minute. Or maybe the refresh only hits the browser cache, and not the server.
OK, let's see if I can grab some of that bounty (booty?), while also testing my explanatory skills :)
So let's start with #1.
So what would a remember me bring to the party?
What's important to distinguish here is the difference between a "session cookie" and a "remember me cookie".
Since HTTP is a stateless protocol, a session cookie is used to tie several requests to a single user. Without it, every single request to your webserver is completely unrelated to every other request. Can you imagine writing applications without sessions? Every request is completely empty, no logins, no session variables..every request is an unknown user! This basically means no web applications!
Now, important thing here is to realise that you absolutely don't want your session to last 24 hours! In my book, this is a very big no-no. The shorter your session is, the safer it is (at least theoretically). Why? Because a session can be hijacked! The longer your session is around, the more chance it has of being hijacked.
For example, imagine a banking application. Also, imagine your user is accessing it on a public PC (our user is not the brightest). So he's managing his account or whatever..and his phone rings. Being an idiot, he takes the call and leaves, without logging out. Do you want your session to expire in 5 minutes, 15 minutes, or 24 hours? Don't know about you, but for something as critical as online banking, I want that session gone ASAP.
Moving on to the "remember me" part.
So session cookie "connects" multiple requests in a single session, what does the "remember me" cookie do? In simple terms: it ties multiple sessions to a single user.
You want your site to be easy and pleasant to use, and logging in is almost never pleasant. It's just an annoying thing you have to do every time before doing that thing you really want to do. A remember me cookie removes that annoyance.
You log in once, check the box, and now you're always logged in on that PC. This is why you should never use "remember me" feature while on a shared PC, because the next person will have your identity. Legitimately. This is why remember me cookies are also a security risk, they can be hijacked much like the session cookie.
Finally, there is one crucial difference between a session cookie and a remember me cookie: expiration. Session cookies normally expire when you close your browser (or after a time you've specified explicitly), whereas remember me cookies typically last for much longer.
Also how come sessions expire even if a user continues to use a
website?
To make it simple, they don't. You must have changed the way cake (or your application) handles sessions. The answer must be somewhere in your code. The reason why you didn't get a satisfactory answer here is because we can't see your code. You'll just have to debug and track what happens to your cookies. JB Nizet gave you some suggestions.
One thing I know that may cause trouble on some servers is cake's security level. Try lowering it in your /Config/core.php:
Configure::write('Security.level', 'medium'); // or 'low'
If that doesn't help, then the answer is definitely in your code. I hope this answer will push you in the right direction!
1.) The difference between a session cookie and "remember me" is that a session cookie has an expiration date of "0". Which means "expire when the browser closes". Whereas "remember me" gives a specific expiration date, say a month from now, to that same session cookie. That's the only difference. You might think this difference in functionality is trivial or meaningless, but consider this: at home I don't want to bother logging in every evening to the same damn Yahoo! account, whereas at work I don't want to bother deleting my cookies every time I have to go take a pee.
2.) Session cookies should not expire even when the application is being used. Where and under what circumstances are you seeing this behavior? It is wrong.
Understand the combination of the security settings combined with the timeouts, that's a very important part. When security is set at a high level sessions might be killed before you expect.
Next to that test with the internal cake session store. That way the local system configuration cannot influence it. It might be that PHP settings override the settings in Cake. So set the session store to Cake. That will create a directory with sessions which you can control.
Likewise it is a combination of server settings and expecting the config of Cake does override these server settings.
If I do this:
Configure::write('Session', array(
'start' => true,
'defaults' => 'cake',
'timeout' => 1,
'cookieTimeout' => 1,
'autoRegenerate' => true
));
/**
* The level of CakePHP security.
*/
Configure::write('Security.level', 'high');
It fixes the issue! So the session last 10 seconds, but If I refresh every 2-3 seconds then I will still be logged in after 10 seconds as the cookie is being refreshed. So it seems that the PHP settings of my hosting environment are/were causing the expiring session/cookie... Why would this happen though?
I have a site which does a few ajax calls on page load. For some reason, CodeIgnitor is inserting 4 sessions (I'm assuming one for each ajax call) as you load the page. I'm storing the sessions in the database.
I'm pretty sure there should only be one session per browser. Firefox seems to generate only one; other browsers seem to create a whole bunch of sessions. Multiple sessions for the same user are giving me some serious authentication problems.
Why is this happening? How can I stop it?
I know the discussion took place while ago, but somebody might find this useful.
By now I've used CI session without storing its data in database. Today I decided to give it a try and immediately run across the same problem: CI was generating new session in every page load.
I checked my server time, timezone, my cookie etc. - everything I could find as a tip on forums - with no result. Then decided to debug the CI Session class myself.
Long story short, it turned out that my user_agent field in my session table was too small - VARCHAR 50 - which cuts the original user_agent string - hence CI doesn't find my session and generates onother one. I just increased the user_agent field size to 200 and everything works like a charm.
I forgot to mention that I use Mac OS X Lion.
Again, hope this will help somebody.
Check the date / time on your client OS, and on your server.
I know its too late, but maybe someone finds this page while looking for the answer...
I think it happens because CI sets an expiration time on the cookie containing the session id and if the time difference between the server and client is higher than the expiration time the cookie gets old and the server will generate a new session for the client on every request. Never took the time to figure out the exact mechanism, but happened to me several times, and this fix always worked.
I've found this topic with same problem: on every page CI generates new session. Possible solution: remove underscored from site name ( NOT "my_test_site.com", but "my-test-site.com"). At least, this helped in my situation.
Check your config.php file and make sure the cookie options are properly filled out. If they are not it cant track the user and it will gen a new session on every page load.
Check the date / time on your client OS, and on your server.
I had the same situation and confirm the solution as a fix
$config['cookie_domain'] = "example.com";
Use your domain name in this snippet.
Is it possible to configure PHP sessions to never expire? I currently have the default 24 minutes set in php.ini - I could whack this up to a couple of weeks or something like that but I was wondering if I can set them to infinite lifetime?
I want to achieve a similar effect to Stackoverflow's: I never have to log in here. Is this achieved on SO with a never-expiring session or some other means?
Also, as a secondary question: How do the expired session files get cleaned up? If someone creates a session and never returns, which process is cleaning up their expired file?
Normally, what appears to be an everlasting session is two things: a session, which expires pretty soon, and a very long-life cookie containing an auto-login token.
There's a great series of responses on sessions and logging-in contained in this StackOverflow question: The Definitive Guide To Website Authentication
Regarding your question about when sessions are cleaned up, there are several php.ini settings for controlling when the garbage collection for sessions is triggered.
Since PHP both allows and encourages you to create your own session data storage handlers, there is no single correct answer to this question.
Answer to secondary question
Session file cleanup is controlled by the following 3 php.ini settings:
session.gc_probability (default value 1)
session.gc_divisor (default value 100)
session.gc_maxlifetime (specified the age after which the session is considered as garbage)
First 2 settings specify the probability of the garbage collection process being started at session start (before or at the very beginning of your script execution, depending on how you have set things up)
In default configuration there is a 1% probability then that this happens. If it does, then files that are older than maxlifetime are cleaned.
As for your first question - why not write a custom session handler, that stores sessions inside the database (if you have one). That way you can see and control the sessions right from inside the database. Handy :)
This is my first time on StackOverflow though I "read" Coding Horror quite often. Anyway...
I'm working on a school/college project using CakePHP and I'm using the built in AuthComponent to support user Authentication (i.e. logging in, etc).
My problem is that it logs me out after very short intervals. It doesn't even have me wait a full session (i.e. closing browser). Sometimes 5 minutes, sometimes 10 and occasionally 15 but not more.
Worst is when it logs me out when I'm calling a method that requires a user to be logged in and it decides to die right before than.
I've searched quite a bit but I can't seem to find an answer. Any help will be appreciated!
I haven't used CakePHP since version 1.1, so I am not sure if this has changed, but you may want to check out your DEBUG level. The lower the DEBUG setting, the lower the value assigned to CAKE_SESSION_TIMEOUT. In 1.1, again, this is all determined in app/config/core.php.
EDIT: Just checked it out, it's been rewritten but the idea remains the same. In core.php look for:
/**
* Session time out time (in seconds).
* Actual value depends on 'Security.level' setting.
*/
Configure::write('Session.timeout', '120');
And increase it so that it takes longer to timeout the session.