Thanks guys.
I think setting the sercure pages to expire seems to be the best option. The next stage would then be to redirect them back to the login page. As for the Referrer suggestion, I'd be sceptical, as this doesn't always come in on the incoming requests anyway. I'm not sure if it would be present on the back reqeusts. Yes, it could also be done through javascript, but that can be disabled.
-----Original Message-----
From: Mike McGuinness [mailto:[EMAIL PROTECTED]]
Sent: 16 August 2001 15:39
To: [EMAIL PROTECTED]
Subject: Re: Timing out Secure session
Christopher,
I'm still in development using the *really* strict rules and I did see
differences in IE vs Mozilla.
Mozilla popped up a dialog and asked me about old data I would need to repost. Ok,
I thought. MS IE 5 displayed a semi nasty page about security restrictions preventing
the use of the back button to repost; please hit refresh. Of course there are a few levels
of security settings for IE which will probably cause different results. I was using the default
settings.
I think IE5 held the http rules pretty well but not very user friendly.
Mozilla was a bit more lax, to use a phrase, and maybe more user friendly.
Thanks for the the comments about 13.13. I'll have to check that out.
Mike
Christopher K. St. John wrote:
Mike McGuinness wrote:
Another alternative is to be *really* strict: res.setHeader("Cache-Control", "no-cache"); res.setHeader("Cache-Control", "no-store"); res.setHeader("Cache-Control", "private"); res.setHeader("Cache-Control", "must-revalidate"); res.setHeader("Expires", "Tue, 25 Dec 1996 12:22:22 GMT"); res.setHeader("Pragma", "no-cache");The last one (Pragma) is for http 1.0 and should work onmost browsers. ... Ref. rfc 2616, section 14.9
Yeah, but then section 13.13 has to go and ruin it allby saying that: "History mechanisms and caches are different. In particular history mechanisms SHOULD NOT try to show a semantically transparent view of the current state of a resource. Rather, a history mechanism is meant to show exactly what the user saw at the time when the resource was retrieved." In other words: the 'back' button is never supposed torevalidate, ever. Some people argue that "no-store"should apply to the history list, but the spec ispretty clear that it doesn't. Of course, that's not very practical, and many browserscorrectly ignore the horribly broken section 13.13, butthey all do it in %!&%$ different ways. Newish versions of Mozilla, for example, will happilyfail to revalidate Pragme: no-cache, but can be convincedusing Cache-Control: no-store. If you use the "really!
strict" set of headers listedabove, does IE revalidate? or does it just pop youback to the previous (stale) page? (When I messed withthis a while back, there were some vesions of IE whereit appeared to be impossible to prevent history-listcaching)--Christopher St. John [EMAIL PROTECTED] http://www.distributopia.com___________________________________________________________________________To unsubscribe, send email to [EMAIL PROTECTED] and include in the bodyof the message "signoff SERVLET-INTEREST".Archives: http://archives.java.sun.com/archives/servlet-interest.htmlResources: http://java.sun.com/products/servlet/external-resources.htmlLISTSERV Help: http://www.lsoft.com/manuals/user/user.html
___________________________________________________________________________ To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff SERVLET-INTEREST". Archives: http://archives.java.sun.com/archives/servlet-interest.html Resources: http://java.sun.com/products/servlet/external-resources.html LISTSERV Help: http://www.lsoft.com/manuals/user/user.html