RE: the "back" button on the weblogout page

["Townsend, Paul" <townsend@xxxxxxxxxxxxx>]

There's a simple way to avoid this messy behavior:  Reverse the order of
local/global logout.  That is, send the user to the weblogin logout
first, and do your local cleanup afterwards.

To implement it, just make your logout links look like this:

https://weblogin.umich.edu/cgi-bin/logout?http://www.myservice.umich.edu
/logout

This will have the effect reversing the logout procedure; instead
running your local logout script and then sending the user to weblogin,
it sends the user to weblogin first with an immediate return to do the
local cleanup.  (You'll need to modify your logout script so that it
doesn't send the user into a loop, but that's fairly trivial)

We use this approach at the B School, and it works pretty well.  Logout
is not initiated until the user sees the "Are you sure?" message and
clicks the "Logout" button.  The Back button works seamlessly, with no
need to code anything into the app, because nothing has happened yet.

In my view, that's how a confirmation screen should work.  Don't do
anything until the user clicks OK.  


Paul Townsend
Sr. Applications Programmer
Ross School of Business

-----Original Message-----
From: Gavin Eadie [mailto:gavin@xxxxxxxxx] 
Sent: Wednesday, September 07, 2005 12:48 PM
To: cosign-discuss@xxxxxxxxx
Subject: the "back" button on the weblogout page

After logging out from an application, the option to log out from the 
weblogin service is presented on a screen with "Back" and "Logout" 
buttons.  The "Back" button tries to take the user to the last page 
they visited.

If this return into the application would be to a "deep" page (one 
that might represent a half-way point in a process the user abandoned 
by clicking application logout), things get a little messy.  It's 
nothing that the application cannot cope with by detecting the 
attempt to reuse a terminated, or nonexistent, session and then 
presenting the user with the application's front door, instead of the 
targeted page.

I also see an Apache cosign directive which looks like it might also be
useful.

    CosignSiteEntry ... [ the URL to redirect to after login  ]

       If this is set to the URL of the application's front page, will 
the behavior be to bring a user who clicks "Back," as in the above 
scenario, to that front page and obviate the need for the application 
to catch the "missing session" case?


Also, in passing, when the user clicks the weblogin logout, their 
next presented page can be specified by the "?http://..."; which may 
be passed to weblogin on the logout request.  Would it make sense to 
have the target of the "Back" button similarly, optionally 
configurable?