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@xxxxxxxx> 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/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
