Grouper Developers Forum

[Jim Fox <>]

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
>
>  
>
>