On Wednesday 08 October 2003 11:23 pm, Manisha Sathe wrote: > thanks all, > > If session has to time out then in that case what shall i do in following > case ?
Just have them log-in again. > > I have a login page, user logins and starts playing (it is a on line game > site), for each action (he tells something to do), i need to check whether > he is login (i.e session on), if yes, then take all session vars and act > accordingly. So do u mean to say that i need to ask for login again if i do > not find any session? Is it a normal practice to do ? Yes. Users rarely complain about coming back to their computer an hour later and having been logged out. Keep in mind that this is 30 minutes of inactivity, not 30 minutes total. The user can be logged in for hours, so long as they are using the session. > > I always wonder what will happen if the user is half way - running some PHP > script at back which calls another script in turn and session ends in > between? May be this question will be very basic, but i always get confuse. Sorry I don't see what you're asking... could you try to re-phrase it? > > I know bit of ASP. I remember it is having something like 'On Session End' > event hadler. but PHP does not have some thing like this ? I'm assuming that just lets you provide code to execute after the session ends. To the best of my knowledge, it doesn't. Then again, I don't think it would be a good idea. Lots of extra overhead, and you shouldn't need a cleanup function if you write the code correctly. Data should be written to the DB periodically throughout the session, not at the end. What exactly would you have this code do? > > Regards, > Manisha > > > > "Evan Nemerson" <[EMAIL PROTECTED]> wrote in message > news:[EMAIL PROTECTED] > > > Comments inline > > > > On Wednesday 08 October 2003 10:23 pm, Chris Shiflett wrote: > > > --- Evan Nemerson <[EMAIL PROTECTED]> wrote: > > > > Well you can change the default from 30 mins to something larger, > > > > but that has security consequences... > > > > > > I am speaking to myself as much as anyone, but we should all try to > > develop > > > > the habit of explaining any such "consequences" that we mention. To do > > > otherwise doesn't really educate the many people who read these > > responses, > > > > whether now or in an archive. It only adds to the mystery of certain > > topics > > > > (such as security). > > > > Well, they _can_ always ask if they don't understand. I agree that it's > > best > > > to give as much information as possible, but that takes a LOT of time. If > > we > > > don't assume any prior knowledge, answering anything would be a huge > > pain. > > > > That being said, I agree that in this case I should have elaborated... > > It's > > > probably a reach for a lot of list readers. > > > > If you have long sessions, the likelyhood that someone will be able to > > steal > > > the session ID and imitate the user increases drastically. It's called > > session hijacking, and any google search (or archive search, probably) > > will > > > yield a wealth of information. > > > > > > Sessions are kind of a hack over HTTP, which is pretty much a > > > > stateless protocol. There's Connection: keep-alive, but not every > > > > browser supports it, and I don't think there's a way to hook into it > > > > from PHP. > > > > > > Well, persistent connections aren't really intended to provide stateful > > > transactions (and they don't). > > > > They most certainly are not, but if they could _theoretically_ be used > > that > > > way. Practicality, however, forbids it. IMO it's a Bad Idea, but still > > worth > > > mentioning. Actually, now I'm thinking about writing a POC just to see if > > it > > > can be done, even in a laboratory setting. > > > > > My favorite example to use is Google, because there are two resources > > that > > > > make up the front page: the HTML and the logo. With previous versions > > > of HTTP, unless a persistent connection was specifically requested, a > > separate > > > > TCP connection was established for each transaction. This meant two TCP > > > connections would be created and destroyed just to render Google. > > Imagine > > > > more elaborate sites, and you can see how this can really cause > > performance > > > > problems. By making persistent connections the default (HTTP/1.1), a > > single > > > > TCP connection can be established, and until all necessary resources > > > are received, the same connection is used. This makes much more sense. > > > The Connection header allows you to specify the desired behavior. > > > > Wow they finally have one image! IIRC, for a long time the logo was > > several > > > small images that looked like a single image. That way, the whitespace > > around > > > the letters didn't have to be included in the image. IMHO that was a cool > > solution. They still avoid superfluous line breaks, which makes me > > happy... > > > > Oh, and every major browser I am aware of does support it, but > > > hopefully you can now see that it is not associated with sessions or > > > even stateful transactions. > > > > Okay well then here's another reason not to rely on keep-alive: Users > > can't > > > copy a URL and paste as an argument to wget -c (or any of the download > > managers). I'm sure there are many, many more reasons, but I sincerely > > doubt > > > I'd have to convice anyone not to use keep-alive for sessions. > > > > > Hope that helps. > > > > > > Chris > > > > > > ===== > > > My Blog > > > http://shiflett.org/ > > > HTTP Developer's Handbook > > > http://httphandbook.org/ > > > RAMP Training Courses > > > http://www.nyphp.org/ramp > > > > -- > > Evan Nemerson > > [EMAIL PROTECTED] > > > > -- > > "Who controls the past controls the future. Who controls the present > > controls > > > the past." > > > > -George Orwell -- Evan Nemerson [EMAIL PROTECTED] -- "To achieve adjustment and sanity and the conditions that follow from them, we must study the structural characteristics of this world first and, then only, build languages of similar structure, instead of habitually ascribing to the world the primitive structure of our language." -Alfred Korzybski -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
