Grouper Developers Forum

[Chris Hyzer <>]

Well, I think all this discussion was moot since I cant seem to get the status code from jquery of an ajax post, it comes back as 0 instead of 302.  Google says this could be because jquery thinks it is a remote ajax, though it isn’t, and debugging through jquery confirms that jquery doesn’t think it is remote.  If anyone has ideas for me to make this work let me know.  Otherwise, I think we have two options:

 

1.       Could have ajax service not be a protected URL (e.g. with cosign), but it does check to see if there is an existing session, and if not, then redirect the user to the current URL.

-or-

2.       If there is any ajax error, try to go a simple GET ajax and see if that is a 302 (or any error?), if so, then give a popup message and redirect to the current URL which should make the user login and start where they left off

-or-

3.       Have a configured grouper ui timeout (e.g. 30 minutes inactivity) where the screen  will redirect to a “Your session has ended screen, click here to start over”.  This could be based on inactivity or not.  Doesn’t help with single sign out, so it doesn’t sound good…  but would probably help with a majority of the cases

 

In any case, if we are doing 2.1.2 soon, I don’t think either of these are feasible in a short time frame (already spent a lot of time on it).  I would lean toward the 2^nd option for security reasons…

 

Thanks,

Chris

 

From: Gagné Sébastien [mailto:]
Sent: Monday, July 23, 2012 9:26 AM
To: Chris Hyzer; Andrew Petro;
Subject: RE: [grouper-dev] RE: Lite UI problems

 

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 :

 

 

 

De : Chris Hyzer []
Envoyé : 20 juillet 2012 11:52
À : Andrew Petro;
Cc : Gagné Sébastien
Objet : RE: [grouper-dev] RE: Lite UI problems

 

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: On Behalf Of Andrew Petro
Sent: Friday, July 20, 2012 11:39 AM
To:
Cc: Gagné Sébastien
Subject: Re: [grouper-dev] RE: Lite UI problems

 

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:

UI is 2.1.0 (haven’t tried 2.1.1)

 

I’m not 100% sure about how CAS works, but I believe the app servers detects that the CAS ticket is expired and sends a redirect (302) to the login page. I believe the problem with the Lite UI is that the AJAX request inside a page won’t do a “regular” HTTP request and _javascript_ might not handle the redirect properly (if it was sent with these type of request).

 

If I do a request for the Lite UI home page directly I am prompted by the login page. The problem is when I try to do an action inside the page when the session is expired.

 

 

De : Chris Hyzer []
Envoyé : 19 juillet 2012 14:45
À : Gagné Sébastien;
Objet : RE: Lite UI problems

 

What is the version of the Lite UI which has internationalization problems?  Have you tried in 2.1?

 

How does the browser know there is a problem with Authn?  Is there a 302 response from the app server when authentication is needed?  So if there is a 302 in ajax it should redirect to the same page which will trigger a logon?

 

Thanks,

Chris

 

From: On Behalf Of Gagné Sébastien
Sent: Thursday, July 19, 2012 2:39 PM
To:
Subject: [grouper-dev] Lite UI problems

 

Hello,

Using the lite UI I found some problems which would be nice if they were addressed in next UI

 

First, accent support is very iffy, we translated part of nav.properties, but sometimes (like on buttons) the html entities were shown (e.g. &eacute;) instead of the value (é). There’s some problems with encoding between Lite UI and Admin UI (one will show the character é while the other will show a question mark)

 

Also, if I enter some text for a grouper entity (an attribute in this case), accents are bugged :

Before Save:

After save :

 

 

Enough of our French eccentricity, there’s also a problem with CAS integration with the Lite UI :

 

We authenticate with CAS server and sessions expires after some time. This is no problem with the admin UI which will redirect you back to the login page to re-authenticate when you click on a link. However, this is not the case with the Lite UI, I will usually get a message box telling me that the XML request failed. If I re-authenticate using the Admin UI and go back in the Lite UI and do the same task, everything is back to normal. I believe this is because of the Ajax behind. It would be nice if there was a way to have a re-authentication (refresh the page maybe ? I think you need a new webrequest to have the app redirect you to the login page)

 

Thanks

 

 

Sébastien Gagné,     | Analyste en informatique

514-343-6111 x33844  | Université de Montréal,

                     | Pavillon Roger-Gaudry, local X-100-11