Re: [PHP] sessions and expirations and isolations
On Tue, Jan 17, 2012 at 5:17 PM, Haluk Karamete halukkaram...@gmail.com wrote: This brings the question to the following; WHEN DOES THE SERVER KNOW THAT A USER IS REALLY GONE OR HE CLOSED HIS BROWSER? Just addressing this quesiton -- you are correct that the browser does not tell the application when it closes. What *does* happen is that the cookie associated with that browser session is destroyed or nullified, thus when the use reopens their browser and opens the application again, there won't be a session cookie sent to the application on start. As explained above, this has nothing to do with how long the session data may be stored on the server, it just won't be accessed if the browser has been closed in the meantime. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] sessions and expirations and isolations
On 17 Jan 2012, at 23:17, Haluk Karamete wrote: 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. You are wrong. What you need to understand is that the cleanup of the data is controlled by a completely separate system to that which enables requests to get access to it. The session.gc_maxlifetime setting controls how long it must be since the session data was saved before it is considered for cleanup. The description above is correct in that the default behaviour is for the session cookie to die with the browser session, but that has absolutely no effect on how long the data will be retained on the server. If you want a full description of how the session cleanup logic works I'm happy to provide it, but you should be able to work it out by looking at the descriptions of the gc_probability, gc_divisor and gc_maxlifetime settings on this page: http://www.php.net/manual/en/session.configuration.php#ini.session.gc-probability -Stuart -- Stuart Dallas 3ft9 Ltd http://3ft9.com/
RE: [PHP] sessions and expirations and isolations
-Original Message- From: Stuart Dallas [mailto:stu...@3ft9.com] Sent: 18 January 2012 12:02 On 17 Jan 2012, at 23:17, Haluk Karamete wrote: 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. You are wrong. What you need to understand is that the cleanup of the data is controlled by a completely separate system to that which enables requests to get access to it. The session.gc_maxlifetime setting controls how long it must be since the session data was saved before it is considered for cleanup. The description above is correct in that the default behaviour is for the session cookie to die with the browser session, but that has absolutely no effect on how long the data will be retained on the server. And you are also possibly wrong that session information is kept in system memory, as the default is for it to be serialized and saved in a regular file on disk. There are other options (database, shared memory, ...), but disk files are the default. Cheers! Mike -- Mike Ford, Electronic Information Developer, Libraries and Learning Innovation, Portland PD507, City Campus, Leeds Metropolitan University, Portland Way, LEEDS, LS1 3HE, United Kingdom E: m.f...@leedsmet.ac.uk T: +44 113 812 4730 To view the terms under which this email is distributed, please go to http://disclaimer.leedsmet.ac.uk/email.htm -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] 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 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
Re: [PHP] sessions and expirations and isolations
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
Re: [PHP] sessions and expirations and isolations
Well Stuart, When I said this 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 did not mean that aspect of the business which you replied to. I did not mean that 2 user's session can get being mixed up. Of course, neither PHP nor ASP would allow that and that's all thru the current session cookie ID - which is nearly impossible to guess for somebody else's session cookie ID for that session time. Instead, I was meaning something totally different. Sorry for not being very clear about it. Here is another shot at it. Here, you are developing an app and the app is being developed under say domain.com/app1/. Let's call this app APP_1 And this app got say 10 php files and these files use lots of some session vars to pass some data from one another. That's the case for APP_1. now you need a second app... which is totally different that APP_1. And that is to be developed under say the same server as say domain.com/APP_2/ and this one too has its 5 php files too. But there is nothing common between two apps. Now, ASP allows me to treat these apps ( APP_1 and APP_2 ) as two separate apps ( virtual apps they call it ) and once I do that ( and that's thru the IS settings ), the sessions vars I store in APP_1 does not get overwritten by the APP_2, even though they may or may not share the ame names... With that, I can set up a session var Age as 43 right there in APP_1 and I can have another session variable in the other app, still named as Age where I store age value as a string, something like say middle-age. If I weren't create these virtual apps at IIS, ASP would have overwritten the value 43 with the value middle-age and vice versa back and forth. I'm trying to understand if the same flexibility is available or not with PHP. I should be able to go the APP_1 and do a _SESSION dump and I should see 10 session variables in there and then I should be able to go APP_2 and there I should se only 8. That's the case with classic ASP. 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
Re: [PHP] sessions and expirations and isolations
On 17 Jan 2012, at 02:21, Haluk Karamete wrote: Well Stuart, When I said this 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 did not mean that aspect of the business which you replied to. I did not mean that 2 user's session can get being mixed up. Of course, neither PHP nor ASP would allow that and that's all thru the current session cookie ID - which is nearly impossible to guess for somebody else's session cookie ID for that session time. Instead, I was meaning something totally different. Sorry for not being very clear about it. Here is another shot at it. Here, you are developing an app and the app is being developed under say domain.com/app1/. Let's call this app APP_1 And this app got say 10 php files and these files use lots of some session vars to pass some data from one another. That's the case for APP_1. now you need a second app... which is totally different that APP_1. And that is to be developed under say the same server as say domain.com/APP_2/ and this one too has its 5 php files too. But there is nothing common between two apps. Now, ASP allows me to treat these apps ( APP_1 and APP_2 ) as two separate apps ( virtual apps they call it ) and once I do that ( and that's thru the IS settings ), the sessions vars I store in APP_1 does not get overwritten by the APP_2, even though they may or may not share the ame names... With that, I can set up a session var Age as 43 right there in APP_1 and I can have another session variable in the other app, still named as Age where I store age value as a string, something like say middle-age. If I weren't create these virtual apps at IIS, ASP would have overwritten the value 43 with the value middle-age and vice versa back and forth. I'm trying to understand if the same flexibility is available or not with PHP. I should be able to go the APP_1 and do a _SESSION dump and I should see 10 session variables in there and then I should be able to go APP_2 and there I should se only 8. That's the case with classic ASP. Of course. I did touch on this in my reply but I obviously wasn't verbose enough. Sessions are tied to an ID, and that ID is (usually) stored in a cookie. Therefore the cookie is what links a session to a user, and it's the limits on that cookie that determine the level of isolation. In the case you describe above, the default behaviour would be for both apps to share the session because the cookie would be set on domain.com with the default path of /. You can change the path with the session.cookie_path setting. See here for more details: http://www.php.net/manual/en/session.configuration.php#ini.session.cookie_path Basically, each app would need to use the ini_set function to set session.cookie_path to /APP_1 or /APP_2 accordingly, before calling session_start. That will effectively isolate the sessions for the two apps in the same way that virtual directories do in ASP. Hope that makes it clearer. -Stuart -- Stuart Dallas 3ft9 Ltd http://3ft9.com/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] sessions and expirations and isolations
great exp. now I'm heading towards the http://www.php.net/manual/en/session.configuration.php#ini.session.cookie_path. you definitely deserved a good chocolate cookie! On Mon, Jan 16, 2012 at 6:38 PM, Stuart Dallas stu...@3ft9.com wrote: On 17 Jan 2012, at 02:21, Haluk Karamete wrote: Well Stuart, When I said this 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 did not mean that aspect of the business which you replied to. I did not mean that 2 user's session can get being mixed up. Of course, neither PHP nor ASP would allow that and that's all thru the current session cookie ID - which is nearly impossible to guess for somebody else's session cookie ID for that session time. Instead, I was meaning something totally different. Sorry for not being very clear about it. Here is another shot at it. Here, you are developing an app and the app is being developed under say domain.com/app1/. Let's call this app APP_1 And this app got say 10 php files and these files use lots of some session vars to pass some data from one another. That's the case for APP_1. now you need a second app... which is totally different that APP_1. And that is to be developed under say the same server as say domain.com/APP_2/ and this one too has its 5 php files too. But there is nothing common between two apps. Now, ASP allows me to treat these apps ( APP_1 and APP_2 ) as two separate apps ( virtual apps they call it ) and once I do that ( and that's thru the IS settings ), the sessions vars I store in APP_1 does not get overwritten by the APP_2, even though they may or may not share the ame names... With that, I can set up a session var Age as 43 right there in APP_1 and I can have another session variable in the other app, still named as Age where I store age value as a string, something like say middle-age. If I weren't create these virtual apps at IIS, ASP would have overwritten the value 43 with the value middle-age and vice versa back and forth. I'm trying to understand if the same flexibility is available or not with PHP. I should be able to go the APP_1 and do a _SESSION dump and I should see 10 session variables in there and then I should be able to go APP_2 and there I should se only 8. That's the case with classic ASP. Of course. I did touch on this in my reply but I obviously wasn't verbose enough. Sessions are tied to an ID, and that ID is (usually) stored in a cookie. Therefore the cookie is what links a session to a user, and it's the limits on that cookie that determine the level of isolation. In the case you describe above, the default behaviour would be for both apps to share the session because the cookie would be set on domain.com with the default path of /. You can change the path with the session.cookie_path setting. See here for more details: http://www.php.net/manual/en/session.configuration.php#ini.session.cookie_path Basically, each app would need to use the ini_set function to set session.cookie_path to /APP_1 or /APP_2 accordingly, before calling session_start. That will effectively isolate the sessions for the two apps in the same way that virtual directories do in ASP. Hope that makes it clearer. -Stuart -- Stuart Dallas 3ft9 Ltd http://3ft9.com/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
