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