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: Scotty Logan <>
  • To: Chris Hyzer <>
  • Cc: "" <>
  • Subject: Re: [grouper-dev] RE: Lite UI problems
  • Date: Fri, 10 Aug 2012 15:47:53 -0700

On Thu, Aug 9, 2012 at 8:15 PM, Chris Hyzer <> wrote:

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.

This would be what the OAuth 2.0 implicit flow is for.  The user authenticates before the Ajax client is downloaded, which means the client can use that session to get an access_token from the authorization endpoint.  The token response usually includes the token's expiration time, so the client can check if the token is still valid before making a request, or it can just catch the 401 error from the API and parse the OAuth error response to check if the token expired.  The client can get a new token by redirecting the user through the authorization endpoint again.  Token expiration can be tied to the authentication session expiration, or it can be a fixed period.

You wouldn't need a full OAuth 2.0 implementation... just enough to support the implicit flow (although someone mentioned Spring Security in an earlier message - it has an OAuth 2.0 implementation that supports the implicit flow).

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

If your data is XML and your login page is invalid XML (i.e. most HTML), or your data is JSON, you can detect the error with jQuery:

        cache: false,
        dataType: 'xml',
        error: function(xhr, status, error) {
          if (error) {
            // handle the error (error === status === 'Forbidden', etc.)
          } else {
            // handle session expiration (error === false, status === 'error')
        success: function(data, status, xhr) {
          // handle data

If there's an error at the HTTP level (4xx, 5xx), the first part of the error handle will run - otherwise it's likely a redirect to an HTML page that jQuery couldn't parse as XML or JSON.


Archive powered by MHonArc 2.6.16.

Top of Page