[Seaside] Re: Logging out from a webpage
Klaus D. Witzel
klaus.witzel at cobss.com
Wed Aug 1 09:35:24 UTC 2007
on Wed, 01 Aug 2007 10:00:59 +0200, you wrote:
> 2007/7/31, Klaus D. Witzel:
>> Hi Philippe,
>> on Tue, 31 Jul 2007 07:02:47 +0200, you wrote:
>> > 2007/7/30, Klaus D. Witzel:
>> >> On Mon, 30 Jul 2007 22:18:57 +0200, Michael Gorsuch wrote:
>> >> > On Mon, Jul 30, 2007 at 04:12:30PM -0400, Richard Eng wrote:
>> >> >> If I ?logout? from a webpage, which takes me to a new webpage, how
>> >> do I
>> >> >> ?invalidate? the previous page or otherwise prevent the user from
>> >> >> revisiting
>> >> >> it (either through the back button or using history)?
>> >> >
>> >> > I would look at WATask's 'isolate' method. This expires previous
>> >> pages.
>> >> It's also possible to tell the browset to rewrite history, see
>> >> for examples. I use that to invalidate the previous page when it can
>> >> done from a click on a hyperlink.
>> > How very uncool ;) How very low-level
>> This is all that Seaside can do: send cryptic messages to a browser at
>> lowest-level it understands and then hope that is looks cool and works
>> cool :)
>> If Seaside can do more to the browser then please tell me.
> Seaside do does not send cryptic messages.
Did I forget the smiley :) Since it cannot send Smalltalk messages (it
could, but ...), I called the "messages" cryptic :)
> It does not use unreliable,
Yes, that's what I'm more interested in (non-JS).
> Seaside uses http to tell the browser
> that the page doesn't exist anymore and the should go look somewhere
>> I'm *not* talking about putting Smalltalk code into methods and classes
>> and, once they work make them available for use and reuse in a component
>> framework, since this is taken for granted.
>> > and unreliable. We use #isolate:
>> > and #expire for this.
>> I'm keen to see what that tells the browser to do, i.e. how pages are
>> expired which are already in its cache "history" and at the time of
>> arrival had no expire-at-logout-time set because logout time is not
>> in advance.
>> Test case: send pages to which the user can return with #back, then
>> #logout and take the browser offline (which is the same as being connect
>> to a so called reliable network). Now demonstrate that the pages cannot
>> accessed any longer, in this case not from the browser's cache
> You can always return with the back button if you enable caching and
> disable JS. This is how the web works and we have to deal with it. But
> no actions will get executed if you click somewhere and you will be
> informed, that this page has expired.
Sure, that's reality. Have no reason to object what you wrote. What I
described earlier cannot be done (or if someone had a solution I'd like to
>> This should take an experienced Seaside developer ca. 1 1/2 minutes.
> See attachment. The sensitive, private information is a counter. Also
> note the difference between expiring just some "pages" with #isolate:
> and the whole session.
Loaded into Damien's sq3.9-7067web07.07.1.image and tested, tells me
<title>That page has expired.</title>
<h1>That page has expired.</h1>
You are being redirected to <a
Thanks for the demo code, Phillipe.
>> > Cheers
>> > Philippe
>> Seaside mailing list
>> Seaside at lists.squeakfoundation.org
More information about the Seaside