http://www.php.net/manual/en/session.configuration.php#ini.session.cookie-lifetime
says that a session.cookie_lifetime of 0 "goes until the browser is closed". Is that the absolute maximum length that the session can have (always wiped when the browser is closed), or would setting a session.cookie_lifetime of, say, 23243245234 yeild a result that would probably last beyond whenever the browser is closed?
More to the point, what php.ini settings would I need to set to make sessions last somewhere along the lines of two days, and is there a security reason to recommend a certain (I would expect lower) time limit, and if so what would the recommended period be?
Intended behavior
Edit: Here is what I want to achieve, perhaps I'll be able to understand the behavior by getting some settings suggestions as opposed to the specific values of the php.ini settings:
I want the session to last as long as possible, up to (approximately) two days.
If the session can last beyond browser close, I would like it to do so (up to approximately two days).
What would I set for php.ini settings (and yes, I have direct edit access to the php.ini) to acheive that?
There are two parameters you need to worry about regarding sessions. The first is the TTL for the cookie, the other is how old a session data file can become before it gets garbage collected.
session.cookie_lifetime determines, in seconds, how long the cookie sent to the browser will last. It defaults to 0, which means until the browser closes. For two days it'd need to be 172800 seconds.
session.gc_maxlifetime determines, also in seconds, how long before session data marked on the server will be regarded as garbage and can be deleted.
Setting these two ini directives should give you sessions that survive for two days, except for one more thing of which you need to be aware.
Some operating systems do automated garbage collection on their default temporary directories. If PHP is configured to store session data there, then if the GC period for the temp directory is short you may find yoruself losing your session before the value in session.gc_maxlifetime is reached. To avoid this, make sure PHP is storing session data to a location other than /tmp or whatever the temporary directory of your host operating system is.
It means that the session is lost at the time the browser gets closed.
That is, the cookie containing that session id gets deleted together with the onclose event of the browser.
session.cookie_lifetime specifies the
lifetime of the cookie in seconds
which is sent to the browser
The recommended period depends basically on what your session needs to hold. Say you want to keep your user logged in the website (remind me), you should go for the largest period. Just as an example.
If you want the session alive for approximately two days, you just count
60 [seconds] * 60 [minutes] * 48 [hours] = 172800 seconds
First off I do not recommend to anyone that they play around with session life unless they are aware of the consequences.
In regards to the your question there are actually two systems in place to manage a session.
Firstly if you are using PHP's default system you are employing a file based session system where by a file is created on your server which holds the actual data of the clients session, this file is normally named the same as the session id. The user then has a cookie send to there browser which holds the session id client side.
The setting you are referring to ONLY defines the life of the cookie in the clients browser not the life of the session.
A setting of 0: causes the cookie to last until the browser is closed.
A setting higher than 0: causes the session to last that many seconds and is only terminated after that time. The browser can be opened and closed as many times as the user wants and the cookie will remain until the time of expiry.
I believe but could be wrong that the setting is only the number of seconds from when the cookie is created and not an actual timestamp but I could be wrong.
You can change this setting in your php.ini or you can use a combination of session_get_cookie_params and session_set_cookie_params
Clarification
Ignoring server side. The client holds a cookie which holds the SessionID and allows them to access there session. If the cookie is lost the client no longer has the ability to access the session and is in essence lost.
A value of 0 will cause the clients browser to keep the cookie until the browser is closed. If the user was to keep there browser open for a week, the cookie would be kept for a week.
A value greater than 0 will cause the clients browser to keep the cookie for that number of seconds. E.g. If the value was set to 172800 seconds (2 days) the cookie would be held by the browser for 2 days. If the browser is closed during this 2 days the cookie is not destroyed, it is only lost after 2 days.
Why use 0
Using 0 is more secure because when a user has finished using your website on a public system and close the browser the cookie is lost and the session can no longer be accessed preventing another user from opening the browser and continuing the session. It is not reliable to presume that a user will end the session manually (e.g. logout) as many don't.
Wait there is the confusion .....
"Session" will not lost if the the browser get closed....its the "Cookies" which get lost on close of browser.
"Session" is altogether is different from "Cookies". Session stays at server and can be destroyed explicitly. Whereas "Cookies" resides at client end and can be destroyed manually or at a particular time interval or on browser close.
Short (but slightly inaccurate) solution
Set session.gc_maxlifetime to 172800 and session.cookie_lifetime to 0.
Extended and more accurate solution
In general, session.gc_maxlifetime is the configuration to control the session’s life time. So setting that directive to 172800 will make the session to expire after 172800 seconds (theoretically). But as the calculation of the age of a session is slightly odd, you might want to implement a more accurate expiration scheme. See my answer to How do I expire a PHP session after 30 minutes? for more information.
And setting the session ID’s cookie lifetime to 0, the cookie will be valid until the browser is closed.
Related
If I have four identical servers hosted on AWS EC2, divided into two groups and the each group is located in different AWS regions. There is one ELB in front of each group. I configured two weighted alias records (not latency based) point to the ELB of each group in the AWS Route53.
Each server has a simple apache2 server installed which display a simple page with different words to distinguish from each other. I started a browser client (made by Selenium library) frequently reloading page with the URL which is the domain name of these servers (pause for 1 seconds) but I found that that the browser (firefox) always return pages from servers in one group instead of returning pages from both group in 50% times as how Weighted Round Robin works.
I also found that if I pause for a relatively longer time, pages from the other group do get returned but as long as I refresh the page frequently. It never changes. Request always hits one group not the other.
I also wrote a simple Java program to keep querying the domain name from AWS Route 53 and the address I got back does change between two group, but the browser seems stuck in the connection with the group it first connected (as long as I frequently refresh)
I suspect it is the problem of TCP connection still alive, but I am not sure. BTW, I have already disabled browser cache and I am using Mac OS X 10.9. (This does happen on Ubuntu as well)
Any ideas will be really appreciated. This issue is really important to my works the deadline of which is approaching. Many many thanks in advance.
Unfortunately, that's normal.
Many, perhaps most, browsers cache the dns response they get from the OS, and the timing of this cache is unrelated to the DNS TTL -- it's at the discretion of the browser developers.
For Firefox, the time by default appears to be 60 seconds, so, not likely to be directly related to keepalives, though there's certainly some potential for that, too... albeit for a shorter time interval, in some cases, since many servers will tear down an idle kept-alive connection before 60 seconds, since a connection idle for so long is a potentially expensive waste of a resource.
Firefox: http://kb.mozillazine.org/Network.dnsCacheExpiration
For a discussion of the issue and observations made of the behavior of different browsers, see also: http://dyn.com/blog/web-browser-dns-caching-bad-thing/
I'm using grails 1.3.5 and I need to automatically log out users from my app when they close their browser or all tabs in which my app is opened.
While there is no particularly reliable way to do this (in any web framework, not just Grails), there are some rather hacky ways you can get close to this, though there are some massive tradeoffs.
In general, since you have a default session timeout, the user will be logged out (in general) when their session expires due to not receiving a request associated with their session. This behavior can be changed depending on your security environment, but we'll assume you are using (sensible) defaults.
This session expiration logout can be abused to mimic logging them out when they have no windows/tabs with your application open in them. To do this, you could have a small piece of JavaScript that continually "pings" your server at whatever interval you specify to keep the session "alive" and keep them logged in. How tight you set these pings is a tradeoff between the load on your server and the window of time where they could close their browser and re-open it and still stay logged in.
Like I said, this is very hacky, but it's functional.
I have scanned RFC 6265 but did not find the answer to the following.
I want to put a naive round-robbin load-balancer in front of multiple servers for a single webapp. The load-balancer does not provide sticky sessions. So a client will typically bounce from one appserver to another on successive requests.
On the first connection, the client has no SID and is randomly routed to, say, server A.
Server A responds with a session cookie, a nonce.
On the next connection, the client includes the SID from server A in the HTTP headers.
This time the client is randomly routed to, say, server B.
Server B sees the SID which (one hopes!) does not match any SID it has issued.
What happens? Does server B just ignore the "bad" SID, or complain, or ignore the request, or what?
The idea is, I don't want to use session cookies at all. I want to avoid all the complexities of stickiness. But I also know that my servers will probably generate -- and more to the point look for -- session cookies anyway.
How can I make sure that the servers just ignore (or better yet not set) session cookies?
I think the answer to this will vary greatly depending on the application that is running on the server. While any load balancer worth its salt has sticky sessions, operating without them can be done as long as all the servers in the pool can access the same session state via a centralized database.
Since you are talking about session IDs, I'm guessing that the application does rely on session state in order to function. In this case, if the request came in with a "bad" session ID, it would most likely be discarded and the user prompted to log in — again, the precise behavior depends on the app. If you were to disable session cookie entirely, the problem would likely get worse since even the absence of an ID would likely result in a login prompt as well.
If you really want to avoid complexity at the load balancer, you will need to introduce some mechanism by which all servers can process requests from all sessions. Typically this takes the form of a centralized database or some other shared storage. This allows session state to be maintained regardless of the server handling that particular request.
Maintaining session state is one of the sticking points (pun intended) of load balancing, but simply ignoring or avoiding session cookies is not the solution.
I set up a test version of a PHP coded website which uses sessions to handle user logins. On the test server, the session would expire on browser close, since copying everything to the "clean" live server, the session stays in place on browser close and the user is still logged in even the next day after full system reboot.
In php.ini
; Lifetime in seconds of cookie or, if 0, until browser is restarted.
; http://www.php.net/manual/en/session.configuration.php#ini.session.cookie-lifetime
session.cookie_lifetime = 0
Which implies that it should expire on browser restart.
I thought maybe it was being overridden somewhere, but if I print_r the session_get_cookie_params in PHP I get
Array
(
[lifetime] => 0
[path] => /
[domain] =>
[secure] =>
[httponly] =>
)
Is there something I am missing?
If you are using google chrome
if you set "continue where I left off", chrome will restore your browsing data and session cookies.
even Facebook login (without "remember me") session is retained.
for more info
google chrome setting
Issue is here that a Firefox has a feature called "Restore last session". If someone uses saving tabs on close then it's the same. When browser restores the last session then all session cookies will be restored too :)
So your session cookie can live forever. You can read more at Firefox session cookies
I was going to add this as a comment on Alexander's excellent answer, but its going to get a bit verbose.
How long the cookie is retained on the browser and how long the session data is retained by the server in the absence of a request are 2 seperate and independent things. There is no way to avoid this due to the stateless nature of HTTP - although there are some things you can do to mitigate what you perceive as a security flaw.
For the browser to access the same session after being closed down and some delay it requires that both the session cookie be retained by the browser (which Alexander has already explained) and for the server to have retained the session data.
The behaviour you describe may be much more pronounced on systems handling a low volume of requests and where the session handler does not verify the TTL of the sesion data (I'm not sure if the default handlers do, or if they just assume that any undeleted session data is considered current).
You've not provided any details of how the 2 servers are configured, notably the session.gc_maxlifetime.
If the session.gc_maxlifetime has expired between requests but the session data is still accessible this implies that the session handler merely considers this as the time at which the session is considered eligible for garbage collection (which, semantically, is what the configuration option is for). However there is a strong case for treating this value as a TTL. To address this you could either force the garbage collection to run more frequently and delete the session data, or use a session handler which ignores session data older than the specified limit.
That you see a difference between the 2 systems may be due to differing values for session.gc_maxlifetime or differences in the frequency of garbage collection or even different session handlers.
After having my VPS upgraded to CentOs 5.5, I began to experience frozen / disconnected shell sessions if I had neglected them for a certain amount of time. Very annoying. The solution I found was to edit /etc/ssh/sshd_config and set the ClientAliveInterval to the desired number of seconds. My understanding is that this essentially substitutes for activity from the client user (me) and so keeps the session from disconnecting.
Having initiated a shell session after making this minor change, I seem to be able to maintain a neglected session. However, just because a thing seems to be working doesn't mean the best, or even correct, approach was necessarily taken.
Is there a better / different way to prevent a shell session from freezing?
The ClientAliveInterval value can increase the sshd timeout, you can try the following command as well
echo "TMOUT=300 >> /etc/bashrc
echo "readonly TMOUT" >> /etc/bashrc
echo "export TMOUT" >> /etc/bashrc
No guarantees, but this is what I recently started using on the server. 10 seconds seems like a short time, but I don't trust my phone to keep the connection alive. I suppose you could increase the number of seconds till the problem starts again, then dial it back.
ClientAliveInterval 10
Sets a timeout interval in seconds after which if no data has been received from the client, sshd(8) will send a message through the encrypted channel to request a response from the client. The default is 0, indicating that these messages will not be sent to the client.
ClientAliveCountMax 200
If it fails, keep trying for about 30 minutes. In other words, keep trying 200x, every 10 seconds. My logic could be flawed though, depending on what happens after 10 seconds. Assuming the client is quiet (like maybe I'm reading) does the "alive" message reset the max count if successful? Is inactivity considered failure? Or is failure a "no acknowledgement" of the alive message? Until I know the answer, I figure it's safe to repeat 200x.
Similar question here, and some decent recommendations...
https://unix.stackexchange.com/questions/400427/when-to-use-clientaliveinterval-versus-serveraliveinterval