| Re: session handler auto log out [message #176093 is a reply to message #176087] |
Wed, 23 November 2011 09:55   |
Erwin Moller
Messages: 228
Registered: September 2010
Karma:
|
Senior Member |
|
|
On 11/23/2011 3:09 AM, Denis McMahon wrote:
> On Tue, 22 Nov 2011 16:55:40 +0100, Arno Welzel wrote:
>
>>> Because the AJAX call will reset the session timer, so the session will
>>> never time out.
>>
>> And where did i say that the AJAX call should be *before* the session
>> times out?
>
> If the ajax call is made after the session has timed out, then you're
> back to the previously discussed situation where you get a request
> without a valid current session ID and do with it as you wish.
>
> Any request, whether ajax initiated, a form submission, clicking a link,
> grabbing an image etc will send the session cookie from the client to the
> server if a session cookie is defined.
Hi Denis,
Are you sure a request for an *image* will modify the Session?
I thought the Session would only be updated if session_start() is used
(directly or indirectly by activation session.auto_start).
For a typical image request (one that goes only through the webserver
and don't call a PHP script to produce an image) I don't think the
webserver bothers to change the session / sessioncookie details.
>
> If php code is invoked to handle the request and that code invokes the
> session handler, then the session timer will be reset and an updated
> session cookie reflecting the new timeout / expiry will be sent to the
> client.
Yes.
So a typical image request will not modify the session, right?
>
>> Hint: It is also possible to implement a session handling on your own.
>
> Then you need to go and write your own session handler. Have fun.
It isn't that hard really.
Only the concurrency can give some problems (make a testingpage
consisting of 100 frames that all call a script, using the same session
is an easy way to test.)
And the documentation on php.net is good enough.
But I avoid using my own sessionhandlers when the built-in session logic
suffices.
But in some situation you *must* take some action when a session expires
without a user/client ("owner" of the session) sending a request, eg
releasing some locks.
I had situations where Person A is modifying a document.
During modification nobody else could open it.
When Person A neatly closes the action, Person B could open that
document and work on it.
Of course, many people simply walk away from their work, and don't close
their work, or log out, hence I had to find a way to find these open
document that should actually be closed, and custom session handlers are
by far the easiest approach.
Regards,
Erwin Moller
>
> Rgds
>
> Denis McMahon
--
"That which can be asserted without evidence, can be dismissed without
evidence."
-- Christopher Hitchens
|
|
|
|
Calendar
Search
Help
Members
Register
Login
Home
]