How to handle session timeout with Ajax

Tagged: ,

This topic has 5 replies, 3 voices, and was last updated 6 years, 2 months ago by [email protected].

  • Author
  • #11062

    We are using OpenAM version 13 to secure our web application (using Apache Web Agent 2.4). Everything works perfectly… Until… either the session is invalidated or the web agent cache expires and the user’s session needs to be validated again because the user initiated a request using AJAX.

    What seems to be happening is if a user initiates a call within our application that uses AJAX the web agent correctly takes over and sends a 302 back to the browser to validate the user’s session, but the response is swallowed up by the browser because it’s a redirect to a login page for an AJAX call.

    What is the best way to handle this situation? Things get even more wonky when the AJAX call is something other than a GET or a POST. We have correctly implemented the CORSFilter, but the second redirect after PreFlight causes OpenAM to return a 405 because it doesn’t know what to do with the PUT (or DELETE).

    BTW… We are running in SSO-only mode. I don’t know if that makes a difference.

     Peter Major

    When using the web policy agent you should be able to utilize the org.forgerock.agents.config.json.url setting to prevent the agent from sending back a 302. This does mean that your application will need to analyze the responses of the AJAX calls to ensure that you are dealing with the invalid session JSON responses correctly.

    An alternative way I heard about in the past was to modify the login page to set a response header that is unique for the login screen. If in the AJAX response you see that unique header, then the JS should redirect to the login page.


    @peter-major Thenks for your response… I am just seeing this.

    I am looking at the admin interface and I don’t see this setting ANY WHERE under the web agent. I am keen on setting it on my individual agents… however, I’m not 100% sure how this is supposed to be used.



    Peter – can you point us in the direction of any documentation around this org.forgerock.agents.config.json.url setting and what it does?

    Are you saying this allows you to specify a url/url pattern for protected urls that the web agent will not return a redirect to the login page for unauthorised requests, but will instead return some kind of “not authorised” JSON response?

    If so, I may also be interested in this.



    ok, for info I have found this mentioned in the snapshot documentation:


    Use regular expressions to specify a list of resource URLs that should trigger JSON-formatted errors to be returned rather than HTTP error codes.

    I’ve just done a quick test on this and it seems setting this value in the Custom Properties section of the agent config, under the Advanced tab, seems to work. It looks like it takes an array of values, so I set the value as follows:


    When attempting to access this URL the policy agent then returned a JSON response, with a 200 HTTP status code (rather than 302), with the following JSON data giving details of the redirect it would normally have returned:

      "error": {
        "errors": [
            "message": "redirect",
            "location": ""
        "code": 302

    So it looks like it might be possible to use this to specify the endpoints your AJAX calls are making, then you would need to check the contents of the response for the error object returned by the policy agent.


    @andyr Yes… that worked. Thanks for pointing the right direction where to set that value.

Viewing 6 posts - 1 through 6 (of 6 total)

You must be logged in to reply to this topic.

©2022 ForgeRock - we provide an identity and access platform to secure every online relationship for the enterprise market, educational sector and even entire countries. Click to view our privacy policy and terms of use.

Log in with your credentials

Forgot your details?