Skip to Content.
Sympa Menu

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

Subject: Grouper Developers Forum

List archive

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

Chronological Thread 
  • From: Jim Fox <>
  • To: Chris Hyzer <>
  • Cc: Gagné Sébastien <>, Andrew Petro <>, "" <>
  • Subject: RE: [grouper-dev] RE: Lite UI problems
  • Date: Fri, 10 Aug 2012 08:43:26 -0700 (PDT)

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.


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.


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


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…





From: Gagné Sébastien
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






On Behalf Of Andrew Petro
Sent: Friday, July 20, 2012 11:39 AM

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,




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?






On Behalf Of Gagné Sébastien
Sent: Thursday, July 19, 2012 2:39 PM

Subject: [grouper-dev] Lite UI problems



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





Sébastien Gagné,     | Analyste en informatique

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

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



Archive powered by MHonArc 2.6.16.

Top of Page