Hi Phillipe,
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 >> >> >> >> - 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. >> > >> > How very uncool ;) How very low-level >> >> 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. > > 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, > obtrusive JavaScript trickery. 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 > else. > >> 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". > > 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 see it). >> 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 <html> <head> <meta http-equiv="refresh" content="3;URL=http://localhost:8080/seaside/loginoutdemo?_k=OPxnZPPN&_s=gDIsKoTbKlwTAuNw"> <title>That page has expired.</title> </head> <body> <h1>That page has expired.</h1> You are being redirected to <a href="http://localhost:8080/seaside/loginoutdemo?_k=OPxnZPPN&_s=gDIsKoTbKlwTAuNw">http://localhost:8080/seaside/loginoutdemo?_k=OPxnZPPN&_s=gDIsKoTbKlwTAuNw</a> </body> </html> Thanks for the demo code, Phillipe. /Klaus > Cheers > Philippe > >> /Klaus >> >> > Cheers >> > Philippe >> >> >> _______________________________________________ >> 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 |
Free forum by Nabble | Edit this page |