CoSign: Collaborative Single Sign-On  

cosign-discuss at
general discussion of cosign development and deployment

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: the "back" button on the weblogout page

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.


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:

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

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?

Copyright © 2002 - 2004 Regents of the University of Michigan :  Page last updated 15-December-2010