Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.php > #3829 > unrolled thread

session handler auto log out

Back to article view | Back to comp.lang.php

Contents

  session handler auto log out DavidB <davidbrotman2768@gmail.com> - 2011-11-19 14:49 -0800
    Re: session handler auto log out Jerry Stuckle <jstucklex@attglobal.net> - 2011-11-19 18:29 -0500
    Re: session handler auto log out Denis McMahon <denismfmcmahon@gmail.com> - 2011-11-20 00:11 +0000
    Re: session handler auto log out Arno Welzel <usenet@arnowelzel.de> - 2011-11-21 15:07 +0100
      Re: session handler auto log out Jerry Stuckle <jstucklex@attglobal.net> - 2011-11-21 09:13 -0500
        Re: session handler auto log out Arno Welzel <usenet@arnowelzel.de> - 2011-11-21 15:31 +0100
          Re: session handler auto log out Jerry Stuckle <jstucklex@attglobal.net> - 2011-11-21 12:46 -0500
            Re: session handler auto log out Arno Welzel <usenet@arnowelzel.de> - 2011-11-22 12:09 +0100
              Re: session handler auto log out The Natural Philosopher <tnp@invalid.invalid> - 2011-11-22 11:18 +0000
                Re: session handler auto log out Jerry Stuckle <jstucklex@attglobal.net> - 2011-11-22 07:20 -0500
                  Re: session handler auto log out Denis McMahon <denismfmcmahon@gmail.com> - 2011-11-22 13:29 +0000
              Re: session handler auto log out Jerry Stuckle <jstucklex@attglobal.net> - 2011-11-22 07:18 -0500
                Re: session handler auto log out Arno Welzel <usenet@arnowelzel.de> - 2011-11-22 16:55 +0100
                  Re: session handler auto log out Jerry Stuckle <jstucklex@attglobal.net> - 2011-11-22 13:18 -0500
                    Re: session handler auto log out Arno Welzel <usenet@arnowelzel.de> - 2011-11-23 10:17 +0100
                      Re: session handler auto log out Jerry Stuckle <jstucklex@attglobal.net> - 2011-11-23 06:12 -0500
                        Re: session handler auto log out Arno Welzel <usenet@arnowelzel.de> - 2011-11-23 16:04 +0100
                          Re: session handler auto log out Jerry Stuckle <jstucklex@attglobal.net> - 2011-11-23 10:39 -0500
                      Re: session handler auto log out Denis McMahon <denismfmcmahon@gmail.com> - 2011-11-23 18:58 +0000
                        Re: session handler auto log out Arno Welzel <usenet@arnowelzel.de> - 2011-11-23 20:42 +0100
                          Re: session handler auto log out Denis McMahon <denismfmcmahon@gmail.com> - 2011-11-23 23:07 +0000
                            Re: session handler auto log out Jerry Stuckle <jstucklex@attglobal.net> - 2011-11-23 23:57 -0500
                              Re: session handler auto log out Arno Welzel <usenet@arnowelzel.de> - 2011-11-24 09:53 +0100
                                Re: session handler auto log out Arno Welzel <usenet@arnowelzel.de> - 2011-11-24 11:19 +0100
                            Re: session handler auto log out Arno Welzel <usenet@arnowelzel.de> - 2011-11-24 09:47 +0100
                  Re: session handler auto log out Denis McMahon <denismfmcmahon@gmail.com> - 2011-11-23 02:09 +0000
                    Re: session handler auto log out Arno Welzel <usenet@arnowelzel.de> - 2011-11-23 10:22 +0100
                    Re: session handler auto log out Erwin Moller <Since_humans_read_this_I_am_spammed_too_much@spamyourself.com> - 2011-11-23 10:55 +0100
                      Re: session handler auto log out Denis McMahon <denismfmcmahon@gmail.com> - 2011-11-23 18:53 +0000
                        Re: session handler auto log out Erwin Moller <Since_humans_read_this_I_am_spammed_too_much@spamyourself.com> - 2011-11-25 10:40 +0100
                          Re: session handler auto log out Denis McMahon <denismfmcmahon@gmail.com> - 2011-11-26 18:36 +0000
      Re: session handler auto log out Erwin Moller <Since_humans_read_this_I_am_spammed_too_much@spamyourself.com> - 2011-11-21 15:41 +0100
        Re: session handler auto log out Arno Welzel <usenet@arnowelzel.de> - 2011-11-21 16:06 +0100

Page 2 of 2 — ← Prev page 1 [2]

#3901

On Wed, 23 Nov 2011 20:42:40 +0100, Arno Welzel wrote:

> Denis McMahon, 2011-11-23 19:58:
> 
>> On Wed, 23 Nov 2011 10:17:45 +0100, Arno Welzel wrote:
>> 
>>>>> Hint: It is also possible to implement a session handling on your
>>>>> own.

>>>> Yup, not easy to do, though.

>>> Recording a timestamp and checking if the time of the last request by
>>> the user (and not only the "check if session is still valid" request)
>>> is not older than x minutes is "not easy"?

>> and the session variables?

> They get lost, as soon as the PHP session times out of course - but by
> doing periodically request using JavaScript this will not happen, so one
> has to implement additional logic to maintain your application specific
> session timeout and to distinguish between the periodically session
> checks via JavaScript and "real" requests caused by user interaction.

I was asking how you're going to handle session variables in your own 
session handler.

It seems you're not going to handle them ....

Rgds

Denis McMahon

[toc] | [prev] | [next] | [standalone]

#3902

On 11/23/2011 6:07 PM, Denis McMahon wrote:
> On Wed, 23 Nov 2011 20:42:40 +0100, Arno Welzel wrote:
>
>> Denis McMahon, 2011-11-23 19:58:
>>
>>> On Wed, 23 Nov 2011 10:17:45 +0100, Arno Welzel wrote:
>>>
>>>>>> Hint: It is also possible to implement a session handling on your
>>>>>> own.
>
>>>>> Yup, not easy to do, though.
>
>>>> Recording a timestamp and checking if the time of the last request by
>>>> the user (and not only the "check if session is still valid" request)
>>>> is not older than x minutes is "not easy"?
>
>>> and the session variables?
>
>> They get lost, as soon as the PHP session times out of course - but by
>> doing periodically request using JavaScript this will not happen, so one
>> has to implement additional logic to maintain your application specific
>> session timeout and to distinguish between the periodically session
>> checks via JavaScript and "real" requests caused by user interaction.
>
> I was asking how you're going to handle session variables in your own
> session handler.
>
> It seems you're not going to handle them ....
>
> Rgds
>
> Denis McMahon

Nope, but that's because he has no idea what he's doing.  I suspect 
someone told him posting in usenet would bring him business.  But the 
failed to impress on him that posting ACCURATE guidance on usenet is 
what's needed.  Otherwise he's just making a fool of himself (and 
driving away business).

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#3907

Jerry Stuckle, 2011-11-24 05:57:

> On 11/23/2011 6:07 PM, Denis McMahon wrote:
>> On Wed, 23 Nov 2011 20:42:40 +0100, Arno Welzel wrote:
>>
>>> Denis McMahon, 2011-11-23 19:58:
>>>
>>>> On Wed, 23 Nov 2011 10:17:45 +0100, Arno Welzel wrote:
>>>>
>>>>>>> Hint: It is also possible to implement a session handling on your
>>>>>>> own.
>>
>>>>>> Yup, not easy to do, though.
>>
>>>>> Recording a timestamp and checking if the time of the last request by
>>>>> the user (and not only the "check if session is still valid" request)
>>>>> is not older than x minutes is "not easy"?
>>
>>>> and the session variables?
>>
>>> They get lost, as soon as the PHP session times out of course - but by
>>> doing periodically request using JavaScript this will not happen, so one
>>> has to implement additional logic to maintain your application specific
>>> session timeout and to distinguish between the periodically session
>>> checks via JavaScript and "real" requests caused by user interaction.
>>
>> I was asking how you're going to handle session variables in your own
>> session handler.
>>
>> It seems you're not going to handle them ....
>>
>> Rgds
>>
>> Denis McMahon
> 
> Nope, but that's because he has no idea what he's doing.  I suspect

Aha. I wonder, how i managed to run my own sites for the last seven
years if i don't have any idea what i'm doing. A miracle ;-)

> someone told him posting in usenet would bring him business.  But the
> failed to impress on him that posting ACCURATE guidance on usenet is
> what's needed.  Otherwise he's just making a fool of himself (and
> driving away business).

I see, you still don't get it and you decided to insult people.



-- 
Arno Welzel
http://arnowelzel.de
http://de-rec-fahrrad.de

[toc] | [prev] | [next] | [standalone]

#3912

Arno Welzel, 2011-11-24 09:53:

> Jerry Stuckle, 2011-11-24 05:57:
> 
>> On 11/23/2011 6:07 PM, Denis McMahon wrote:
>>> On Wed, 23 Nov 2011 20:42:40 +0100, Arno Welzel wrote:
>>>
>>>> Denis McMahon, 2011-11-23 19:58:
>>>>
>>>>> On Wed, 23 Nov 2011 10:17:45 +0100, Arno Welzel wrote:
>>>>>
>>>>>>>> Hint: It is also possible to implement a session handling on your
>>>>>>>> own.
>>>
>>>>>>> Yup, not easy to do, though.
>>>
>>>>>> Recording a timestamp and checking if the time of the last request by
>>>>>> the user (and not only the "check if session is still valid" request)
>>>>>> is not older than x minutes is "not easy"?
>>>
>>>>> and the session variables?
>>>
>>>> They get lost, as soon as the PHP session times out of course - but by
>>>> doing periodically request using JavaScript this will not happen, so one
>>>> has to implement additional logic to maintain your application specific
>>>> session timeout and to distinguish between the periodically session
>>>> checks via JavaScript and "real" requests caused by user interaction.
>>>
>>> I was asking how you're going to handle session variables in your own
>>> session handler.
>>>
>>> It seems you're not going to handle them ....
>>>
>>> Rgds
>>>
>>> Denis McMahon
>>
>> Nope, but that's because he has no idea what he's doing.  I suspect
> 
> Aha. I wonder, how i managed to run my own sites for the last seven
> years if i don't have any idea what i'm doing. A miracle ;-)
> 
>> someone told him posting in usenet would bring him business.  But the
>> failed to impress on him that posting ACCURATE guidance on usenet is
>> what's needed.  Otherwise he's just making a fool of himself (and
>> driving away business).
> 
> I see, you still don't get it and you decided to insult people.

I'm not sure if you will understand it - but as a "quick & dirty"
demonstration of what i'm talking about:

<http://arnowelzel.de/samples/sessiondemo.php>

And the source for this::

<http://arnowelzel.de/samples/sessiondemo.php.txt>



-- 
Arno Welzel
http://arnowelzel.de
http://de-rec-fahrrad.de

[toc] | [prev] | [next] | [standalone]

#3906

Denis McMahon, 2011-11-24 00:07:

> On Wed, 23 Nov 2011 20:42:40 +0100, Arno Welzel wrote:
> 
>> Denis McMahon, 2011-11-23 19:58:
>>
>>> On Wed, 23 Nov 2011 10:17:45 +0100, Arno Welzel wrote:
>>>
>>>>>> Hint: It is also possible to implement a session handling on your
>>>>>> own.
> 
>>>>> Yup, not easy to do, though.
> 
>>>> Recording a timestamp and checking if the time of the last request by
>>>> the user (and not only the "check if session is still valid" request)
>>>> is not older than x minutes is "not easy"?
> 
>>> and the session variables?
> 
>> They get lost, as soon as the PHP session times out of course - but by
>> doing periodically request using JavaScript this will not happen, so one
>> has to implement additional logic to maintain your application specific
>> session timeout and to distinguish between the periodically session
>> checks via JavaScript and "real" requests caused by user interaction.
> 
> I was asking how you're going to handle session variables in your own 
> session handler.
> 
> It seems you're not going to handle them ....

Yep - because it is not neccessary *replace* the PHP session handler -
just some additional logic is needed to "emulate" a timeout and to
destroy the session if the timeout is reached.


-- 
Arno Welzel
http://arnowelzel.de
http://de-rec-fahrrad.de

[toc] | [prev] | [next] | [standalone]

#3881

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.

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.

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

Rgds

Denis McMahon

[toc] | [prev] | [next] | [standalone]

#3885

Denis McMahon, 2011-11-23 03:09:

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

Which can be handled of course.

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

Maybe you should have a look to DokukWikis session handling as an example.


-- 
Arno Welzel
http://arnowelzel.de
http://de-rec-fahrrad.de

[toc] | [prev] | [next] | [standalone]

#3887

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

[toc] | [prev] | [next] | [standalone]

#3894

On Wed, 23 Nov 2011 10:55:36 +0100, Erwin Moller wrote:

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

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

Read what I wrote again:

1) Any request ... will send the session cookie from the client to the 
server if a session cookie is defined.

This is something that the client does - if it has valid (non expired) 
cookies for the server and makes a request to the server, it sends the 
cookies.

So yes, the client browser sends the cookies with every request, 
including images etc.

If the request is then served by php (and you can serve any content with 
php) _and_ that php invokes the session handler, then the php session 
timer is reset in the server, and an updated session cookie will be sent 
back to the client browser.

eg if my web page includes <img src="server/getimage.php?imgid=76">

and getimage.php looks something like:

<?php
session_start();
$imageId = 2;
if (isset($_POST['imgid'])) $tmpImgId = intval($_POST['imgid']);
if ($tmpImgId > 1 && $tmpImgId < 1000) $imageId = $tmpImgId;
$imgFile = "/disks/images/webimages/{$imageId}.png"
if (file_exists($imgFile)) {
    $size = getimagesize($imgFile);
    if $size) {
        header('Content-Type: ' . $size['mime'];);
        header('Content-Length: ' . filesize($imgFile));
        ob_clean();
        flush();
        readfile($imgFile);
        exit;
    }
    else {
    // error - not an identifiable image file
    }
}
else {
// error - file doesn't exist
}
?>

(I may not have included all the relevant error handling, validations and 
verifications)

Then requesting this image will reset any session expiry timer on the 
server.

Rgds

Denis McMahon

[toc] | [prev] | [next] | [standalone]

#3927

On 11/23/2011 7:53 PM, Denis McMahon wrote:
> On Wed, 23 Nov 2011 10:55:36 +0100, Erwin Moller wrote:
>
>> 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.
>
>> 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).
>
> Read what I wrote again:
>
> 1) Any request ... will send the session cookie from the client to the
> server if a session cookie is defined.
>
> This is something that the client does - if it has valid (non expired)
> cookies for the server and makes a request to the server, it sends the
> cookies.
>
> So yes, the client browser sends the cookies with every request,
> including images etc.
>
> If the request is then served by php (and you can serve any content with
> php) _and_ that php invokes the session handler, then the php session
> timer is reset in the server, and an updated session cookie will be sent
> back to the client browser.
>
> eg if my web page includes<img src="server/getimage.php?imgid=76">
>
> and getimage.php looks something like:
>
> <?php
> session_start();

etc..

<snip>

Hi Dennis,

OK, Then we agree completely.

The reason I interrupted was simply that we were discussing updating 
session expiration. In that context your former posting could easily be 
misinterpreted, although you didn't write it exactly that the session 
expiration would be updated by a typical image request (no PHP involved).
And I just wanted to make that point clear. :-)

Regards,
Erwin Moller

-- 
"That which can be asserted without evidence, can be dismissed without 
evidence."
-- Christopher Hitchens

[toc] | [prev] | [next] | [standalone]

#3945

On Fri, 25 Nov 2011 10:40:29 +0100, Erwin Moller wrote:

> The reason I interrupted was simply that we were discussing updating
> session expiration. In that context your former posting could easily be
> misinterpreted, although you didn't write it exactly that the session
> expiration would be updated by a typical image request (no PHP
> involved). And I just wanted to make that point clear. :-)

Yeah, there were two points I was trying to get across:

a) If the client has a session cookie applicable to a request that it is 
making, it sends the cookie; and

b) If the server handles the request with php that invokes the session 
handler, then the session timeout will get updated

If both above conditions (a and b) are true, it doesn't matter what's 
being requested (pdf files, favicon, linked style sheets, javascript 
files, images, archives of some sort whether compressed or not, ajax 
requests etc), the session timer gets updated in the process of servicing 
the request and an updated session cookie is issued.

But I thought I made it fairly clear originally that I was only talking 
about cases where the request was served by a php script that invoked the 
session handler in the process.

Rgds

Denis McMahon

[toc] | [prev] | [next] | [standalone]

#3842

On 11/21/2011 3:07 PM, Arno Welzel wrote:
> DavidB, 2011-11-19 23:49:
>
>> Is there a way to model a session handler to auto logout after a specified
>> period of time without refreshing the page? Something similar to a bank
>> website that auto logs me out and redirects me to another page.
>
> If you want to force the client to redirect the user to another page as
> soon as the session on the *server* times out you must do periodically
> checks on the client e.g. using AJAX.
>
>

Hi Arno,

That approach could bite you in the back.
For example: If your session timeout is 30 minutes, and you check each 
10 minutes via AJAX, you'll never log out because the AJAX request 
"resets" the time-out to a new 30 minutes.
This can all be circumvented (if you know how Sessions work in PHP), but 
I would advise the OP to follow Denis's advice and simply use a 
window.setTimeout() in JavaScript. Much easier.

Regards,
Erwin Moller


-- 
"That which can be asserted without evidence, can be dismissed without 
evidence."
-- Christopher Hitchens

[toc] | [prev] | [next] | [standalone]

#3843

Erwin Moller, 2011-11-21 15:41:

> On 11/21/2011 3:07 PM, Arno Welzel wrote:
>> DavidB, 2011-11-19 23:49:
>>
>>> Is there a way to model a session handler to auto logout after a specified
>>> period of time without refreshing the page? Something similar to a bank
>>> website that auto logs me out and redirects me to another page.
>>
>> If you want to force the client to redirect the user to another page as
>> soon as the session on the *server* times out you must do periodically
>> checks on the client e.g. using AJAX.
>>
>>
> 
> Hi Arno,
> 
> That approach could bite you in the back.
> For example: If your session timeout is 30 minutes, and you check each 
> 10 minutes via AJAX, you'll never log out because the AJAX request 
> "resets" the time-out to a new 30 minutes.

Of course i assumed that the AJAX request will not reset the session
timeout (and yes, i know how sessions work in PHP).

> This can all be circumvented (if you know how Sessions work in PHP), but 
> I would advise the OP to follow Denis's advice and simply use a 
> window.setTimeout() in JavaScript. Much easier.

I agree - setTimeout() is the easies solution in most cases. But you
have to take care that any further interaction will immediatly cancel
the timeout. Depending on the structure of the site and how interaction
is done (e.g. using AJAX and not complete reloads of the page), a simple
setTimeout() may not be enough.


-- 
Arno Welzel
http://arnowelzel.de
http://de-rec-fahrrad.de

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.php

csiph-web