Grouper Developers Forum

[Chris Hyzer <>]

Ok, if the server is down, the request hangs.  If there is a server exception 
or error, it returns a 200 with error message popup.  If there is a status 0 
I agree with you that it is probably a session problem.  So, I have this in 
2.1.2:

https://bugs.internet2.edu/jira/browse/GRP-835

set the message to user in nav.properties:

guiAjaxSessionProblem = 

If the ajax gets an error (it doesnt know its a 302), then it shows a confirm 
where the user can decide if they want to refresh which will cause a login.  
If they dont want to do that, they could copy/paste something or screenshot, 
or login in another browser tab...

Thanks,
Chris

-----Original Message-----
From: Jim Fox 
[mailto:]
 
Sent: Friday, August 10, 2012 11:43 AM
To: Chris Hyzer
Cc: Gagné Sébastien; Andrew Petro; 

Subject: RE: [grouper-dev] RE: Lite UI problems



It's not just jquery.  All browsers seems to automatically follow
302s.  I've never found a way to tell them not to.  My general
solution is to assume the status return of zero is an indication of
that relogin redirection.  When I get back a status=0 I put up a note
for the user to reload the page, which causes a reauthentication.

Jim


On Thu, 9 Aug 2012, Chris Hyzer wrote:

> Date: Thu, 9 Aug 2012 20:15:38 -0700
> From: Chris Hyzer 
> <>
> To: Gagné Sébastien 
> <>,
>     Andrew Petro 
> <>,
>     
> ""
>  
> <>
> Subject: RE: [grouper-dev] RE: Lite UI problems
> 
> 
> 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 2nd 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 :
> 
> [IMAGE]
> 
>  
> 
>  
> 
>  
> 
> De : Chris Hyzer 
> [mailto:]
> 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: 
> 
>  
> [mailto:]
>  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 
> [mailto:]
>       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: 
> 
>  
> [mailto:]
>  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:
> 
> [IMAGE]
> 
> After save :
> 
> [IMAGE]
> 
>  
> 
>  
> 
> 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
> 
>  
> 
>  
> 
> 
>