 |
cosign-discuss at umich.edu
|
|
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.
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?
| 
