Session expiry

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
24 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Session expiry

Amos-15
Hi Seasiders,

I'm wondering how best to handle and avoid session expiry in Seaside.
I know I can set the time that a session lives to any number of
seconds, but even a ridiculously high number there isn't really what I
want. If a page is open in a dusty old tab in my browser for a year, I
still want to get to the right page if I click on a link some day,
rather than being redirected to the start page. ;-)

Let's say I'm trying to create a site with a public (unrestricted)
section and a privileged section restricted to registered users and
admins. I want pages in the former section to *not* expire at all, and
I want to be able to find out how much time is left in the session of
the latter and, if it does expire, redirect to a "session has expired"
type page. Is that possible? (I mean, hey, it's Smalltalk, so of
course it's possible, but how do I best go about doing it?)

I've subclassed WASession and set that to be my application's
#sessionClass. The subclass has an instance variable 'user' and
methods #isUserLoggedIn and #isUserNotLoggedIn etc. So far, so good. I
can see from #isActive on WAExpiringHandler that one of the conditions
is 'self secondsSinceLastAccess < self timeoutSeconds', which makes
sense. However, if I have the following method on my subclass:

secondsToSessionExpiry
        ^self timeoutSeconds - self secondsSinceLastAccess

it always returns timeoutSeconds, i.e. secondsSinceLastAccess always
seems to be 0. Investigating this, I find out that the value is 'Time
totalSeconds - self lastAccess', i.e. it depends on the instance
variable lastAccess - which is apparently only ever (two cases) set to
'Time totalSeconds'...!?! Is that intentional? Should I be overriding
this behaviour? Am I on the wrong track here?

I'd like to end up with a "session countdown" similar to the
"periodical" component in the scriptaculous demo, only with something
like "this session is valid for another hh:mm" instead of the actual
time.

Any pointers as to what I should override (#pageExpired, #isActive,
#lastAccess, etc.) would be greatly appreciated.

Cheers,

Amos
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Reply | Threaded
Open this post in threaded view
|

Re: Session expiry

John Thornborrow
Hi,

Rather than looking for non-expiring sessions, I'd recommend you look
into creating permanent entry points in your application.

Pier has this functionality, but it really isn't too difficult to make
your own implementation by using criteria in a URI and the
#initialRequest: message on your applications root object.

Regards,
John

Amos wrote:

> Hi Seasiders,
>
> I'm wondering how best to handle and avoid session expiry in Seaside.
> I know I can set the time that a session lives to any number of
> seconds, but even a ridiculously high number there isn't really what I
> want. If a page is open in a dusty old tab in my browser for a year, I
> still want to get to the right page if I click on a link some day,
> rather than being redirected to the start page. ;-)
>
> Let's say I'm trying to create a site with a public (unrestricted)
> section and a privileged section restricted to registered users and
> admins. I want pages in the former section to *not* expire at all, and
> I want to be able to find out how much time is left in the session of
> the latter and, if it does expire, redirect to a "session has expired"
> type page. Is that possible? (I mean, hey, it's Smalltalk, so of
> course it's possible, but how do I best go about doing it?)
>
> I've subclassed WASession and set that to be my application's
> #sessionClass. The subclass has an instance variable 'user' and
> methods #isUserLoggedIn and #isUserNotLoggedIn etc. So far, so good. I
> can see from #isActive on WAExpiringHandler that one of the conditions
> is 'self secondsSinceLastAccess < self timeoutSeconds', which makes
> sense. However, if I have the following method on my subclass:
>
> secondsToSessionExpiry
> ^self timeoutSeconds - self secondsSinceLastAccess
>
> it always returns timeoutSeconds, i.e. secondsSinceLastAccess always
> seems to be 0. Investigating this, I find out that the value is 'Time
> totalSeconds - self lastAccess', i.e. it depends on the instance
> variable lastAccess - which is apparently only ever (two cases) set to
> 'Time totalSeconds'...!?! Is that intentional? Should I be overriding
> this behaviour? Am I on the wrong track here?
>
> I'd like to end up with a "session countdown" similar to the
> "periodical" component in the scriptaculous demo, only with something
> like "this session is valid for another hh:mm" instead of the actual
> time.
>
> Any pointers as to what I should override (#pageExpired, #isActive,
> #lastAccess, etc.) would be greatly appreciated.
>
> Cheers,
>
> Amos
> _______________________________________________
> seaside mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>
>
>  
>


Pinesoft Computers are registered in England, Registered number: 2914825. Registered office: 266-268 High Street, Waltham Cross, Herts, EN8 7EA



This message has been scanned for viruses by BlackSpider MailControl - www.blackspider.com

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Reply | Threaded
Open this post in threaded view
|

Re: Session expiry

Lukas Renggli
Check out the mailing list archive. This is a FAQ.

For example to ensure the persistency of a session as long as the user
keeps its window open can be done by adding some Scriptaculous code to
your page:

html request
     every: (sessionExperyTime - 5 seconds);
     callback: []

This will trigger an asynchronous request 5 seconds before the session
expires (given a correct vaue of sessionExpiryTime) that keeps the
session alive for another sessionExpiryTime seconds.

Lukas

--
Lukas Renggli
http://www.lukas-renggli.ch
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Reply | Threaded
Open this post in threaded view
|

Re: Session expiry

Amos-15
Thanks, Lukas, I did see similar questions in the archives, but the
answer only ever seems to be a workaround, not a complete solution (at
least for me). I'll see if I can work out something for myself just to
satisfy my own curiosity - hopefully without breaking the framework
;-)

However, your comment answers my other question as to why the session
expiry time was always equal to the session duration: I hadn't
realised that the 'every: 1 second' bit effectively causes a request
to the server every second (hence resetting the expiry time every
second), I'd assumed it was simply JavaScript running on the client
(obviously wrong in hindsight).

Which begs the question: is there some other way to show the remaining
session time without triggering a request? Otherwise my idea about
showing the remaining time is doomed :-(

@John: thanks, I'll probably do it that way, since the public part of
the site should be bookmarkable etc.

On 1/2/08, Lukas Renggli <[hidden email]> wrote:

> Check out the mailing list archive. This is a FAQ.
>
> For example to ensure the persistency of a session as long as the user
> keeps its window open can be done by adding some Scriptaculous code to
> your page:
>
> html request
>      every: (sessionExperyTime - 5 seconds);
>      callback: []
>
> This will trigger an asynchronous request 5 seconds before the session
> expires (given a correct vaue of sessionExpiryTime) that keeps the
> session alive for another sessionExpiryTime seconds.
>
> Lukas
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Reply | Threaded
Open this post in threaded view
|

Re: Session expiry

Lukas Renggli
> Thanks, Lukas, I did see similar questions in the archives, but the
> answer only ever seems to be a workaround, not a complete solution (at
> least for me). I'll see if I can work out something for myself just to
> satisfy my own curiosity - hopefully without breaking the framework
> ;-)

No, that's a propre solution.

> However, your comment answers my other question as to why the session
> expiry time was always equal to the session duration: I hadn't
> realised that the 'every: 1 second' bit effectively causes a request
> to the server every second (hence resetting the expiry time every
> second), I'd assumed it was simply JavaScript running on the client
> (obviously wrong in hindsight).

I wouldn't set it to trigger every second. This causes an unnecessary
high load on the server. A value that is just a bit shorter than the
expiry time is fine.

> Which begs the question: is there some other way to show the remaining
> session time without triggering a request? Otherwise my idea about
> showing the remaining time is doomed :-(

Sure, using JavaScript. You take one of the many countdown scripts
from the web, add and initialize it with the session expiry time
whenever you render a page.

Lukas

--
Lukas Renggli
http://www.lukas-renggli.ch
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Reply | Threaded
Open this post in threaded view
|

Re: Session expiry

Amos-15
> > Thanks, Lukas, I did see similar questions in the archives, but the
> > answer only ever seems to be a workaround, not a complete solution (at
> > least for me). I'll see if I can work out something for myself just to
> > satisfy my own curiosity - hopefully without breaking the framework
> > ;-)
>
> No, that's a propre solution.

Sorry, I respectfully disagree. And everyone that I've shown Seaside
to, as much as they immediately liked it, the reaction to the handling
of expired sessions is always something that brings up a frown. And
while using JavaScript to spice up websites is great, sites *should*
work for browsers without it, or with JavaScript disabled.

> > However, your comment answers my other question as to why the session
> > expiry time was always equal to the session duration: I hadn't
> > realised that the 'every: 1 second' bit effectively causes a request
> > to the server every second (hence resetting the expiry time every
> > second), I'd assumed it was simply JavaScript running on the client
> > (obviously wrong in hindsight).
>
> I wouldn't set it to trigger every second. This causes an unnecessary
> high load on the server. A value that is just a bit shorter than the
> expiry time is fine.

The 1 second I mentioned was in regard to the countdown, similar to
the 'Periodical' component like I said. Obviously I wouldn't be
resetting the session time every second... ;-)

> > Which begs the question: is there some other way to show the remaining
> > session time without triggering a request? Otherwise my idea about
> > showing the remaining time is doomed :-(
>
> Sure, using JavaScript. You take one of the many countdown scripts
> from the web, add and initialize it with the session expiry time
> whenever you render a page.
>
> Lukas

Sounds like that's the only way to do it since sending a request to
the server every second isn't really an option. Thanks, I'll give it a
try.
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Reply | Threaded
Open this post in threaded view
|

Re: Session expiry

Lukas Renggli
> > > Thanks, Lukas, I did see similar questions in the archives, but the
> > > answer only ever seems to be a workaround, not a complete solution (at
> > > least for me). I'll see if I can work out something for myself just to
> > > satisfy my own curiosity - hopefully without breaking the framework
> > > ;-)
> >
> > No, that's a propre solution.
>
> Sorry, I respectfully disagree. And everyone that I've shown Seaside
> to, as much as they immediately liked it, the reaction to the handling
> of expired sessions is always something that brings up a frown. And
> while using JavaScript to spice up websites is great, sites *should*
> work for browsers without it, or with JavaScript disabled.

Sure, this approach gracefully degrades to the default session expiry
behavior of Seaside. The JavaScript approach spices up the experience
so that as long as you keep the window open the session never expires.
If you want something else, such as bookmark-able URLs, you
(additionally) need something else.

Lukas

--
Lukas Renggli
http://www.lukas-renggli.ch
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Reply | Threaded
Open this post in threaded view
|

Re: Session expiry

Amos-15
On 1/2/08, Lukas Renggli <[hidden email]> wrote:

> > > > Thanks, Lukas, I did see similar questions in the archives, but the
> > > > answer only ever seems to be a workaround, not a complete solution (at
> > > > least for me). I'll see if I can work out something for myself just to
> > > > satisfy my own curiosity - hopefully without breaking the framework
> > > > ;-)
> > >
> > > No, that's a propre solution.
> >
> > Sorry, I respectfully disagree. And everyone that I've shown Seaside
> > to, as much as they immediately liked it, the reaction to the handling
> > of expired sessions is always something that brings up a frown. And
> > while using JavaScript to spice up websites is great, sites *should*
> > work for browsers without it, or with JavaScript disabled.
>
> Sure, this approach gracefully degrades to the default session expiry
> behavior of Seaside. The JavaScript approach spices up the experience
> so that as long as you keep the window open the session never expires.
> If you want something else, such as bookmark-able URLs, you
> (additionally) need something else.

This default session expiry behaviour is exactly what gets my goat...
;-) There's nothing graceful, imho, about clicking on a link and being
sent, by default, to the site's start page. If the default were to
send users to a simple "session expired" page, that would change
things completely for me...
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Reply | Threaded
Open this post in threaded view
|

Re: Session expiry

Lukas Renggli
> This default session expiry behaviour is exactly what gets my goat...
> ;-) There's nothing graceful, imho, about clicking on a link and being
> sent, by default, to the site's start page. If the default were to
> send users to a simple "session expired" page, that would change
> things completely for me...

Override #handleExpiredRequest: in WAApplication.

Lukas

--
Lukas Renggli
http://www.lukas-renggli.ch
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Reply | Threaded
Open this post in threaded view
|

Re: Session expiry

Amos-15
> Override #handleExpiredRequest: in WAApplication.

Brilliant, exactly what I was looking for. Hopefully I'll have more
time to try it out tomorrow - thanks for your time and patience with
an impatient Seaside newbie :-)
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Reply | Threaded
Open this post in threaded view
|

Re: Session expiry

Lukas Renggli
> Brilliant, exactly what I was looking for. Hopefully I'll have more
> time to try it out tomorrow - thanks for your time and patience with
> an impatient Seaside newbie :-)

No problem, I agree that there could (and should) be an easier way,
for example that a custom handler class can be selected in the
configuration application.

Lukas

--
Lukas Renggli
http://www.lukas-renggli.ch
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Reply | Threaded
Open this post in threaded view
|

Re: Session expiry

Boris Popov, DeepCove Labs (SNN)
In reply to this post by Amos-15
Re: [Seaside] Session expiry

Why not show a session expired notice on the home page then when this happens, care to see the code? I can dig it up, its really simple.

Cheers!

-Boris (via BlackBerry)

----- Original Message -----
From: [hidden email] <[hidden email]>
To: Seaside - general discussion <[hidden email]>
Sent: Wed Jan 02 04:09:57 2008
Subject: Re: [Seaside] Session expiry

On 1/2/08, Lukas Renggli <[hidden email]> wrote:
> > > > Thanks, Lukas, I did see similar questions in the archives, but the
> > > > answer only ever seems to be a workaround, not a complete solution (at
> > > > least for me). I'll see if I can work out something for myself just to
> > > > satisfy my own curiosity - hopefully without breaking the framework
> > > > ;-)
> > >
> > > No, that's a propre solution.
> >
> > Sorry, I respectfully disagree. And everyone that I've shown Seaside
> > to, as much as they immediately liked it, the reaction to the handling
> > of expired sessions is always something that brings up a frown. And
> > while using JavaScript to spice up websites is great, sites *should*
> > work for browsers without it, or with JavaScript disabled.
>
> Sure, this approach gracefully degrades to the default session expiry
> behavior of Seaside. The JavaScript approach spices up the experience
> so that as long as you keep the window open the session never expires.
> If you want something else, such as bookmark-able URLs, you
> (additionally) need something else.

This default session expiry behaviour is exactly what gets my goat...
;-) There's nothing graceful, imho, about clicking on a link and being
sent, by default, to the site's start page. If the default were to
send users to a simple "session expired" page, that would change
things completely for me...
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside


_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Reply | Threaded
Open this post in threaded view
|

Re: Session expiry

Randal L. Schwartz
In reply to this post by Amos-15
>>>>> "Amos" == Amos  <[hidden email]> writes:

Amos> Sorry, I respectfully disagree. And everyone that I've shown Seaside
Amos> to, as much as they immediately liked it, the reaction to the handling
Amos> of expired sessions is always something that brings up a frown. And
Amos> while using JavaScript to spice up websites is great, sites *should*
Amos> work for browsers without it, or with JavaScript disabled.

Do these same people also expect to go to to an airline website, stop halfway
through selecting the departure city and arrival city, and come back to that a
week later to continue their purchase?

I don't expect that.  In fact, in the "real world", I've sometimes encountered
timeouts as short as 10 minutes, annoying because I was quickly "comparison
shopping" amongst multiple travel options.

This is what a seaside "session" is... a specific conversation for a specific
purpose, one which can be reasonably expected to be completed in a reasonably
short period of time.

If you want longer state, don't call it a session, and figure out a way
to return a long-departed browser to that same state.

Consider Amazon.com.  You have three levels there:

- permanent URLs for products, making them googleable
- session info (I'm logged in as Randal, currently in the second page of
  checking out)

and in between

- my shopping cart, where I can park something for a week (or a few months!)
  while I'm comparison shopping.

Maybe what you're looking for is that third level... where you can "park"
some state for the currently logged-in user.  In that case, you need
some sort of storage keyed by a user ID.  The literature on that is
numerous, so I won't repeat it.

Would that solve it for you?

--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<[hidden email]> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Reply | Threaded
Open this post in threaded view
|

Re: Session expiry

Sophie424
In reply to this post by Lukas Renggli

"Lukas Renggli" <[hidden email]> wrote in message
> For example to ensure the persistency of a session as long as the user
> keeps its window open can be done by adding some Scriptaculous code to
> your page:
>
> html request
>     every: (sessionExperyTime - 5 seconds);
>     callback: []

Where should this ideally be?



_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Reply | Threaded
Open this post in threaded view
|

Re: Re: Session expiry

keith1y
itsme213 wrote:

> "Lukas Renggli" <[hidden email]> wrote in message
>  
>> For example to ensure the persistency of a session as long as the user
>> keeps its window open can be done by adding some Scriptaculous code to
>> your page:
>>
>> html request
>>     every: (sessionExperyTime - 5 seconds);
>>     callback: []
>>    
>
> Where should this ideally be?
>
>  
I put it in a decorator attached to the root component... its in the
Helper framework as the KeepAliveHelper, just load Jetsam (or the
Jetsam-Helpers sub package) add WAHelperConfiguration to you settings
and enable the KeepAlivehelper

Keith
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Reply | Threaded
Open this post in threaded view
|

Re: Session expiry

Sophie424
In reply to this post by Lukas Renggli

"Lukas Renggli" <[hidden email]> wrote in message
> For example to ensure the persistency of a session as long as the user
> keeps its window open can be done by adding some Scriptaculous code to
> your page:
>
> html request
>     every: (sessionExperyTime - 5 seconds);
>     callback: []

Would #periodical be equivalent? Can this go into <head> with #updateRoot
and WAHtmlRoot#addScript:aString?

Or does this go into <body> and need to be wrapped like:
 html paragraph
  class: 'hidden';
  script: (html periodical
    frequency: 10 seconds ; "just put 10 for testing"
    callback: []);
  with: ''.

Also, would this be put into #renderContentOn: of a Page-level object? I
feel I need a MyPage which always wraps every page, simply holding onto a
single top-level component, and I would like to know if there is a simpler
way:

MyPage >>
My instances represent page-level objects. They can provide a place for page
level stuff like:
- batched list of dirty components waiting to be Ajax-redrawn
- page-level insertion e.g. keep-alive callback
To use a component as top-level page do:
Component class>> new
 ^ MyPage with: self new

Thanks - Sophie



_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Reply | Threaded
Open this post in threaded view
|

Re: Re: Session expiry

keith1y
itsme213 wrote:

> "Lukas Renggli" <[hidden email]> wrote in message
>  
>> For example to ensure the persistency of a session as long as the user
>> keeps its window open can be done by adding some Scriptaculous code to
>> your page:
>>
>> html request
>>     every: (sessionExperyTime - 5 seconds);
>>     callback: []
>>    
>
> Would #periodical be equivalent? Can this go into <head> with #updateRoot
> and WAHtmlRoot#addScript:aString?
>
> Or does this go into <body> and need to be wrapped like:
>  html paragraph
>   class: 'hidden';
>   script: (html periodical
>     frequency: 10 seconds ; "just put 10 for testing"
>     callback: []);
>   with: ''.
>
> Also, would this be put into #renderContentOn: of a Page-level object? I
> feel I need a MyPage which always wraps every page, simply holding onto a
> single top-level component, and I would like to know if there is a simpler
> way:
>
> MyPage >>
> My instances represent page-level objects. They can provide a place for page
> level stuff like:
> - batched list of dirty components waiting to be Ajax-redrawn
> - page-level insertion e.g. keep-alive callback
> To use a component as top-level page do:
> Component class>> new
>  ^ MyPage with: self new
>
> Thanks - Sophie
>
>  
Why reinvent the wheel?

Keith
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Reply | Threaded
Open this post in threaded view
|

Re: Session expiry

Amos-15
In reply to this post by Boris Popov, DeepCove Labs (SNN)
> Why not show a session expired notice on the home page then when this
> happens, care to see the code? I can dig it up, its really simple.

Yes please :-)
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Reply | Threaded
Open this post in threaded view
|

Re: Session expiry

Amos-15
In reply to this post by Randal L. Schwartz
> Amos> Sorry, I respectfully disagree. And everyone that I've shown Seaside
> Amos> to, as much as they immediately liked it, the reaction to the handling
> Amos> of expired sessions is always something that brings up a frown.
>
> Do these same people also expect to go to to an airline website, stop halfway
> through selecting the departure city and arrival city, and come back to that a
> week later to continue their purchase?

Nice strawman, but please re-read the OP ;-)
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Reply | Threaded
Open this post in threaded view
|

Re: Re: Session expiry

Lukas Renggli
In reply to this post by Sophie424
> Would #periodical be equivalent?

#periodical want's to update some DOM element, like the
#updater.#request just performs an empty callback on the server and
does not update anything on the client.

> Can this go into <head> with #updateRoot
> and WAHtmlRoot#addScript:aString?

It is the best, if you use

  self session addLoadScript: (...)

to add it. This makes sure that all resources are properly loaded and
initialized script is evaluated.

> Or does this go into <body> and need to be wrapped like:
>  html paragraph
>   class: 'hidden';
>   script: (html periodical
>     frequency: 10 seconds ; "just put 10 for testing"
>     callback: []);
>   with: ''.

That should work as well.

   html script: (...)

Lukas

--
Lukas Renggli
http://www.lukas-renggli.ch
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
12