Re: Browser refresh sends username/password after log out -- URGENT

[Ingo Struck <ingo () ingostruck de>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi...

> More clearly the issue here is also that:
>
> 1.) We login using username/password
> 2.) Suppose we have browsed 7 pages after log in
> and then we say logout and we get logout message so
> after logging in this is the 8th page.
>
> 3.) Now after this we just do 1 back, so
> effectively we should bein the 7th page that we had
> browsed.
>
>  4.) Now we do a refresh( this is again on the 7th
> page and not on the login page) and the same
> request that we had sent in the login form is being
> resent. This is what i am wondering that how come
> the refresh sends the form fields that were entered
> in the Login Form and not the "Logout" request
> which we had sent from the 7th page.
> 5)hope I am making the question clear.

Ok, maybe now the issue is a bit clearer. :o)
This sounds like a real bug in the browser (but only because
of the 7 in there). It would be interesting then, which browser
exactly (name, version) shows this behaviour (I have a guess, but
don't want to discriminate vendors here...)

If it's only the *third* page, then it's clearly in conformance to
browser's history:
1. you request the login page with a get
2. the login page is displayed (first page)
3. you fill in the form and send a POST somewhere, the browser
   caches the submitted data
4. the page you see now is the *result* of a POST operation (second page)
5. you log off, the result is the "logged out" page (third page)
6. you go "back" to a page which is a result of a POST operation (2nd)
7. you say "refresh", the browser replays the request to obtain the same
   result as before

If there is only one more visited page inbetween, the browser clearly 
shouldn't replay the first page's parameters and it is a bug then.
NOTE: I have seen some issues with POST and 302 redirections.
This is due to a flaw in the HTTP specification (it could be interpreted in 
two ways). Some browsers replay the POST parameters to the redirected
page, some others dont. I had some weird replays of former requests within
that scenario too.

However, the method with the "nonce" / transaction number works
for all flavours of that bug: with the transaction number you can
effectively prevent any kind of request replay (be it unintended, deliberate
or due to bugs in the user agent).

Kind regards

Ingo

- -- 
ingo () ingostruck de
Use PGP: http://ingostruck.de/ingostruck.gpg with fingerprint
C700 9951 E759 1594 0807  5BBF 8508 AF92 19AA 3D24
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.0 (GNU/Linux)

iD8DBQE/MLKahQivkhmqPSQRAkdlAKCzvm6op7EeazY6+RYbhnaE4qhs0wCdHVf/
6BQ/jqvtUYp07rgrKr8/lSo=
=8vJd
-----END PGP SIGNATURE-----