Re: sessions and expirations and isolations

Back to this session expiration... that old quote said... <begin> The default behaviour for sessions is to keep a session open indefinitely and only to expire a session when the browser is closed. This behaviour can be changed in the php.ini file by altering the line: session.cookie_lifetime = 0 If you wanted the session to finish in 5 minutes you would set this to: session.cookie_lifetime = 300. <end> Reflecting on this a little more, I got interested in the part that says "The default behaviour for sessions is to keep a session open indefinitely and only to expire a session when the browser is closed." How would do the server know that a browser is closed? No browser sends such a data to a server. If you re-open your browser, sure you will get asked to relogin ( cause that session id cookie is gone ) but that does not mean that old session data has been erased form the server. How could it? The only way for that to happen is to run session_destroy programmatically but for that your users has to click on a link. Certainly, closing a browser won't cause that! This brings the question to the following; WHEN DOES THE SERVER KNOW THAT A USER IS REALLY GONE OR HE CLOSED HIS BROWSER? I'm afraid session.cookie_lifetime = 0 keeps all session data ( that is past and present ) in server memory until a server restart/stop takes place. Correct me if I'm wrong. On Mon, Jan 16, 2012 at 4:19 PM, Stuart Dallas <stuart@3ft9.com> wrote: > On 16 Jan 2012, at 22:51, Haluk Karamete wrote: > >> Hi, in ASP, sessions expire when the client does not request an asp >> page for more than 20 min. (The 20 min thing is a server level setting >> - which can be changed by IIS settings )  And sessions work out of the >> box. >> >> I use sessions a lot. So, most likely, I would keep that style in my >> PHP apps too. >> >> I read the following about PHP sessions...  I wanted to know how >> accurate this info is. >> >> <quote> >> The default behaviour for sessions is to keep a session open >> indefinitely and only to expire a session when the browser is closed. >> This behaviour can be changed in the php.ini file by altering the >> line: >> >> session.cookie_lifetime = 0 >> If you wanted the session to finish in 5 minutes you would set this to: >> >> Listing 23 Keeping a session alive for five minutes (listing-23.txt) >> session.cookie_lifetime = 300. >> Remember to restart your web server after making this change. >> </quote> > > That's totally accurate, except that it doesn't touch upon how sessions are cleaned > up... > >> Now, if this info is correct and it is this simple, why do we have >> some elaborate posts like this one? >> >> >> http://stackoverflow.com/questions/520237/how-do-i-expire-a-php-session-after-30-minutes > > ...which explains that post. The session.cookie_lifetime is simply the expiry time that will be > set on the cookie that specifies the visitor's session ID. That ID is used as the unique > identifier on the server in the session storage system (defaults to files of serialized data). If > you want to have more precise control over the session lifetime (though I can't see any reason > why you would need to) then you can write your own session handler and implement the timeout logic > yourself. You could also handle it by storing a timestamp in the session and using that to decide > whether the session data should be considered valid (as described in the accepted answer on that > post). > >> What do you do when you write a PHP app that relies on sessions? how >> do you manage the server memory allocation issues? >> Say you wanted to keep session vars alive for 20 min ( from the last >> request from the client ) and you wanted your server to completely >> empty the session if there no request, no new php page is requested >> from that client within that next 20 min. And if a client requests a >> page say on the 19th min, session gets extended another 20 from that >> time on, just like the ASP works. > > The only reason there would be memory allocation issues is if you're storing huge amounts > of data in the session. If you are then I'd suggest that you either re-architect your > application so you don't need to, or implement a custom storage mechanism for that data that > doesn't use the session system. > >> My second question on session is abut keeping sessions apart from one >> another - if such a concept exists... >> >> Let's say you have a session var FirstName in app1 and another session >> variable exactly named as FirstName in app2. >> how do you keep them seperate? >> >> In ASP, I create a virtual app at the IIS server - assigning a virtual >> dir path to the app, and from that point on, any page being served >> under that virtual path is treated as an isolated ASP app and thus the >> sessions are kept isolated and not get mixed up by asp pages that do >> not live under that virtual app path. > > > I don't know much about the way ASP implements sessions but I highly doubt there is > anything significantly different in there to the way PHP does it.. For all intents and purposes the > isolation of a given user's session is guaranteed by the use of cookies. As I mentioned > earlier, the session ID is stored in a cookie. Cookies are not shared between domain names, so there > is no way that two sites, or "applications", could use the same session [1]. > > -Stuart > > [1] This is not entirely true, but since it requires some nasty trickery to make it happen > it's not something you need to worry about unless it sharing sessions is required which is > incredibly rare and almost certainly another sign of poor architecture! > > -- > Stuart Dallas > 3ft9 Ltd > http://3ft9.com/