Logging out from a webpage

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

Thanks,
Richard
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

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.

Michael Gorsuch
http://www.michaelgorsuch.org
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

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

- http://www.google.com/search?q=javascript+location.replace+history

for examples. I use that to invalidate the previous page when it can be  
done from a click on a hyperlink.

/Klaus

> Michael Gorsuch
> http://www.michaelgorsuch.org


_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Actually, the #isolate: method is in WAComponent. I can¹t find any
documentation for it. Looking at the code, I tried to infer the correct
usage, but I can¹t get it to work.

I tried sending the message to the object representing the previous page *at
the time of logout*. No go. (The method requires a block as an argument but
I have no idea what this block is for, so I passed an empty block.)

Can someone explain the correct usage of #isolate: ? When to send the
message? To what object is the message sent? And what's the block argument
for?

Thanks,
Richard

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

Michael Gorsuch


_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

2007/7/31, Richard Eng <[hidden email]>: Have you looked at the senders like WAStoreTask >> #go? It prevents
going into the block again with the back button once you are outside
it.

If you want to expire the whole session send #expire to the session.

Cheers
Philippe

_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

2007/7/30, Klaus D. Witzel <[hidden email]>:
How very uncool ;) How very low-level and unreliable. We use #isolate:
and #expire for this.

Cheers
Philippe
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Hi Philippe,

on Tue, 31 Jul 2007 07:02:47 +0200, you wrote:

This is all that Seaside can do: send cryptic messages to a browser at the  
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.

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 known  
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 be  
accessed any longer, in this case not from the browser's cache "history".

This should take an experienced Seaside developer ca. 1 1/2 minutes.

/Klaus

> Cheers
> Philippe


_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

I think I see what WAStoreTask is doing, but I still couldn't make #isolate:
work. Must be something really wonky about my program architecture.

Anyway, #expire works quite nicely, so I'll go with that.

Thanks for the tip.

Regards,
Richard

------------------
Have you looked at the senders like WAStoreTask >> #go? It prevents
going into the block again with the back button once you are outside
it.

If you want to expire the whole session send #expire to the session.

Cheers
Philippe

_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

> I think I see what WAStoreTask is doing, but I still couldn't make #isolate:
> work. Must be something really wonky about my program architecture.
>
> Anyway, #expire works quite nicely, so I'll go with that.

Have a look at our first Seaside paper. As far as I remember it deeply
discusses the use of #isolate:

http://www.iam.unibe.ch/~scg/Archive/Papers/Duca04eSeaside.pdf

Cheers,
Lukas

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

Yes, I saw the code. And I tried to apply it. But my situation is rather
unique, I think...

In my main login page, I have:

 loginForm := (GSLoginForm new
  onSave: [self call: GSServiceCentre new].

...as per someone's previous suggestion. This allows GSServiceCentre to
replace the entire page, rather than just the login component.

But no matter how I apply #isolate:, it just won't work. Maybe it's because
GSServiceCentre is a WAComponent, rather than a WATask, I dunno. But I think
it's more likely that I'm doing something architecturally unexpected here...

Regards,
Richard

-------------
> I think I see what WAStoreTask is doing, but I still couldn't make
> #isolate:
> work. Must be something really wonky about my program architecture.
>
> Anyway, #expire works quite nicely, so I'll go with that.

Have a look at our first Seaside paper. As far as I remember it deeply
discusses the use of #isolate:

http://www.iam.unibe.ch/~scg/Archive/Papers/Duca04eSeaside.pdf

Cheers,
Lukas

_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Actually, I've encountered a strange problem:

    self session expire.

...works fine in IE, but not in any other browser (Firefox, Opera, Safari).
Why is this???

renderLogoutOn: html
 html div
  class: 'sidebaritem';
  with:
   [html div
    class: 'sbicontent';
    with:
     [html paragraph: [html text: 'Hello ', userFullName fullName].
     html anchor
      callback:
       [self session expire.];
      with: [html paragraph id: 'red'; with: [html strong: 'Logout']]]]

Correct me if I'm wrong, but I think I found a Seaside bug...

Regards,
Richard

----------
Anyway, #expire works quite nicely, so I'll go with that.

Thanks for the tip.

Regards,
Richard

_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

On 31/07/07, Richard K Eng <[hidden email]> wrote:
> Actually, I've encountered a strange problem:
>
>     self session expire.
>
> ...works fine in IE, but not in any other browser (Firefox, Opera, Safari).
> Why is this???

What version of Seaside are you using? It works fine here, with
session cookies either enabled or disabled.
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

I'm using the latest stable dev image from Damien--I believe it's Seaside
2.7 with Squeak 3.9.

Richard


On 31/07/07, Richard K Eng <richard.eng at rogers.com> wrote:
> Actually, I've encountered a strange problem:
>
>     self session expire.
>
> ...works fine in IE, but not in any other browser (Firefox, Opera, Safari).
> Why is this???

What version of Seaside are you using? It works fine here, with
session cookies either enabled or disabled.


_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

On 01/08/07, Richard Eng <[hidden email]> wrote:
> I'm using the latest stable dev image from Damien--I believe it's Seaside
> 2.7 with Squeak 3.9.

Hmm. In what way does it fail to work for you? Are you using session
cookies? (If not, does the _s component of your URLs change after
expiring the session?)
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

In Firefox, Opera, and Safari, after you perform "self session expire", you
can still go back to previous webpages. In IE 7 under Vista, you can't.

So it works for IE, but not for any other browser.

Can anyone verify that this is the case with Seaside 2.7/Squeak 3.9
(Damien's stable image)?

Perhaps I should upgrade to Seaside 2.8 alpha, but before I do that, I want
to be certain that 2.7 is indeed the culprit. I shouldn't be basing my work
on alpha software, if I can help it.

I don't know about session cookies; I haven't done anything explicit with
them. But with Firefox, after I do the expiry, I do see the _k and _s in the
URLs as I backtrack. With IE, I don't see _k and _s...I presume this is
correct behavior.

Thanks,
Richard


On 01/08/07, Richard Eng <richard.eng at rogers.com> wrote:
> I'm using the latest stable dev image from Damien--I believe it's Seaside
> 2.7 with Squeak 3.9.

Hmm. In what way does it fail to work for you? Are you using session
cookies? (If not, does the _s component of your URLs change after
expiring the session?)


_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

On 01/08/07, Richard Eng <[hidden email]> wrote:
> In Firefox, Opera, and Safari, after you perform "self session expire", you
> can still go back to previous webpages. In IE 7 under Vista, you can't.

Sure this isn't a caching issue? (Do the links on the would-be expired
pages actually work?) The code you pasted works fine for me with 2.7
and Safari/Firefox.
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Damn, you're right! The would-be expired pages don't work.

Okay, so it's a caching issue. But here's a potentially dangerous situation:
What if the would-be expired pages contain sensitive, private information?
If you logout and walk away, someone can go to your computer, click the Back
button and see your info. This is not good.

So it's not enough to merely expire your pages, you have to HIDE them...

Suggestions?

Regards,
Richard


On 01/08/07, Richard Eng <richard.eng at rogers.com> wrote:
> In Firefox, Opera, and Safari, after you perform "self session expire", you
> can still go back to previous webpages. In IE 7 under Vista, you can't.

Sure this isn't a caching issue? (Do the links on the would-be expired
pages actually work?) The code you pasted works fine for me with 2.7
and Safari/Firefox.


_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

On 01/08/07, Richard Eng <[hidden email]> wrote:
> So it's not enough to merely expire your pages, you have to HIDE them...

Well, this is really orthogonal to session expiry. Expiring the
session prevents the session being _used_ again, but doesn't do
anything about data that's still on the client (like a cached version
of the page).

Seaside tries to avoid this issue by sending a no-cache header with
every page, but getting browsers to actually respect this in every
case is basically impossible.
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

2007/8/1, Richard Eng <[hidden email]>:
> Damn, you're right! The would-be expired pages don't work.
>
> Okay, so it's a caching issue. But here's a potentially dangerous situation:
> What if the would-be expired pages contain sensitive, private information?
> If you logout and walk away, someone can go to your computer, click the Back
> button and see your info. This is not good.

This is a browser issues. HTTPS pages are in general not cached and
you wouldn't want sensitive, private information to be sent
unencrypted over the internet anyway.

> So it's not enough to merely expire your pages, you have to HIDE them...

Besides the #expire you can also do a redirect to:
self session redirectTo: self session application baseUrl

Cheers
Philippe
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

2007/7/31, Klaus D. Witzel <[hidden email]>: Seaside do does not send cryptic messages. It does not use unreliable,
obtrusive JavaScript trickery. Seaside uses http to tell the browser
that the page doesn't exist anymore and the should go look somewhere
else.
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.

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

Cheers
Philippe

_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside