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 <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
