grouper-dev - RE: [grouper-dev] RE: Lite UI problems
Subject: Grouper Developers Forum
List archive
- From: Chris Hyzer <>
- To: Andrew Petro <>, "" <>
- Cc: Gagné Sébastien <>
- Subject: RE: [grouper-dev] RE: Lite UI problems
- Date: Fri, 20 Jul 2012 15:51:48 +0000
- Accept-language: en-US
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… Thanks, Chris From: [mailto:]
On Behalf Of Andrew Petro 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. So, first, more generally, how does the AJAX-loving Lite UI cope when one's session with the Grouper web application expires, such that it's trying to make AJAX requests
into a session that no longer exists? Presumably those AJAX requests fail. In some interesting way? Ideally the Lite UI _javascript_ would be smart enough to detect that and show a message that says "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. It might be the case that CAS enters into this in that a CAS client library in front of Grouper has been configured to intercept and redirect those AJAX requests for web
service endpoints, such that in the case where the user's session expired, it's trying to redirect them to the CAS login screen so the user can log in. That might be an overly broad configuration of the CAS client library -- ideally only actually-user-facing
paths would be redirected for login, whereas web service requests would be allowed to reach Grouper which can presumably respond to them with a more web-service-domain-specific error response (i.e. whatever the Grouper Lite UI _javascript_ expected for an error
response. :) ) 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. Kind regards, Andrew 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
- [grouper-dev] RE: Lite UI problems, Gagné Sébastien, 07/19/2012
- Re: [grouper-dev] RE: Lite UI problems, Andrew Petro, 07/20/2012
- RE: [grouper-dev] RE: Lite UI problems, Chris Hyzer, 07/20/2012
- RE: [grouper-dev] RE: Lite UI problems, Gagné Sébastien, 07/23/2012
- RE: [grouper-dev] RE: Lite UI problems, Chris Hyzer, 07/20/2012
- Re: [grouper-dev] RE: Lite UI problems, Andrew Petro, 07/20/2012
- [grouper-dev] RE: 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.