Subject: Grouper Developers Forum
- From: Gagné Sébastien <>
- To: "Chris Hyzer" <>, "Andrew Petro" <>, <>
- Subject: RE: [grouper-dev] RE: Lite UI problems
- Date: Mon, 23 Jul 2012 09:26:21 -0400
I think a simple « go back to the login page » is enough, and a nice “your session timed out” message like Andrew suggested would be ideal. If you want to be fancy you could tell them to use another window to relogin then click OK, when the user clicks OK you could then check if the session is back and stay on the same window without losing anything (if the session isn’t valid, you would redirect to the login page)
As for Admin UI vs Lite UI timeout, I might not have been 100% clear : I believe they share the same session, so if I do work in the Admin UI, the Lite UI will stay active and vice-versa. What I pointed out was, when the session timed-out (no work in either UI), if I use the Admin UI to re-login it brings back the Lite UI.
For your information, here is the error I get in the Lite UI clicking an AJAX button :
These are good points, and I will consider them.
In the admin UI, the session is timed out, and the GET or POST to the server redirects the user to the login screen (whatever that login is).
If a user has 60 minutes of inactivity (or whatever it is set for), and the user goes back to the screen and clicks something, I think they would expect a login screen for a page submit or ajax or whatever. For security this might be better anyway in the case where the user walked away from the computer and didn’t log out.
In other ajax UIs Ive seen (e.g. yahoo mail, facebook detects the logout and prompts you to login without letting you save what you are working on), if an ajax request hits a timed out session (or logged out session), the screen just redirects to the login screen. Grouper isn’t something where you put a lot of work in a screen that had no submits that will be lost…
CAS isn’t the problem here, it is Grouper Ajax and session expiration, the same problem would be for shib or cosign or whatever…
Ideally we would have the screen automatically logout like a bank site after however much inactivity, and prompt the user a minute before it happens, but that can introduce problems and might be overengineering in this case…
CAS was mentioned, so i feel called upon to reply to this providing what insight I can, but alas I'm not speaking from direct experience with configuring good CAS authentication to Lite UI. So, for whatever it's worth:
I'd try to think of this as much as possible as a session expiration problem rather than as a CAS problem. CAS should really be an implementation detail of how one gets a logged in session with Grouper. CAS wants to be an authenticated session broker, not an authenticated session manager.
"Yo! Your session timed out! You're no longer logged in to Grouper! So, you need to log in to Grouper again. Click Here to do that! Cool? Cool."
Simply redirecting the whole page to a path requiring login might be an okay second choice, but I'd argue users don't expect their UI to suddenly redirect, they'd more appreciate a message indicating that re-login is required and the opportunity to trigger this themselves, possibly first getting a good idea of what they were in the middle of so they can pick up as best they can after their session is fixed.
Arguably, Lite UI should detect and handle the case where response to asynchronous requests is "weird", i.e. a redirect to a user-facing login UI or otherwise not the expected response, since of course CAS integrations won't be the only integrations that might make these responses wonky in the case where sessions expire.
The configuration mechanism for what URLs, if any, are redirected for CAS login (in the case where Grouper Java servlet application session is not already logged in and the immediate request does not present a validatable service ticket as a request parameter on the URL) varies by CAS client library. If it's a Java Servlet Filter integration we're talking about here, it's a matter of the paths filtered in web.xml.
Insert here very polite and gentle suggestion that Grouper should consider implementing Spring Security or Apache Shiro to provide arguably better integration point for CAS and other login options and more standardized handling of what requests for paths that ought to have been authenticated but weren't are handled in what ways.
PS: I'd worry a little bit that there's something else wrong with this story, in that, why wasn't the interaction with the admin UI keeping the Grouper web application session alive, such that the session shouldn't have timed out, such that the Lite UI's AJAX calls should have been happily working just fine and re-login shouldn't have been required???
On Thursday, July 19, 2012 at 2:57 PM, Gagné Sébastien wrote:
- [grouper-dev] Lite UI problems, Gagné Sébastien, 07/19/2012
- [grouper-dev] RE: Lite UI problems, Chris Hyzer, 07/19/2012
Archive powered by MHonArc 2.6.16.