Re: the "back" button on the weblogout page

[Cory Snavely <csnavely@xxxxxxxxx>]

Back in May of 2003, I suggested that the central logout script take a 
URL argument for the Back button that could override the Javascript that 
is there now. Not sure if such a thing was ever implemented, but it 
sounds like it would fit the bill here.

Being able to pass URLs for both successful logout (which already 
exists) and "canceled" logout would give folks the flexibility to take 
either approach.

I recognize folks are sometimes hamstrung by the application they are 
trying to integrate with CoSign, so having more than one option for the 
way this can be set up is good.

I also recognize some folks might like the somewhat higher security of 
clearing the application session before sending the user off to the 
central logout script. Sure, it's easy enough to SSO back in if the 
browser is still open (and newly-discussed authentication-forcing 
features are not in play), but some vulnerability is reduced there.

c

Townsend, Paul wrote:
> 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?