Uploaded image for project: 'OpenAM'
  1. OpenAM
  2. OPENAM-9648

Invalid Session that causes CDATA[null] response make Web Agent not reauthenticate

    Details

    • Type: Bug
    • Status: Resolved
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: 12.0.3, 13.5.0
    • Fix Version/s: 12.0.5, 13.5.1
    • Component/s: session
    • Labels:
    • Sprint:
      AM Sustaining Sprint 27
    • Support Ticket IDs:

      Description

      When sessionservice get some invalid sessionid, it may return

      <ResponseSet vers="1.0" svcid="session" reqid="0">
      <Response><![CDATA[null]]></Response>
      </ResponseSet>
      

      There is more other areas that causes this then the one fixed in OPENAM-8910.
      The impact of this is that Web agent when receiving this and not an exception response will not do the right thing for an invalid token and forever stuck returning forbidden rather than goto the logon page to get a new session token.

      Here's some analysis done with report for an enduser.

      The other place that OPENAM-8910 did not handle is that in SessionRequestHandler.java

       (Exception ex) {
      141            SessionService.sessionDebug.error(
      142                    "SessionRequestHandler encounterd exception", ex);
      143            sres.setException(ex.getMessage()); <--- ex.getMessage() == NULL
      144        }
      

      Should guard against ex.getMessage() == null due to the failure that NPE may happen. so that CDATA[nul] is returned (and how this is originated in the first place). As we should address this by doing something like replace line 143 like and it will address all the NPE issues that may happen. This handle with the fix although some NPE cleanup may be needed over the code as encountered by this enduser.

      String exmsg = ex.getMessage();
      if (exmsg == null) exmsg = "SomeNPE"; // To prevent disabling the exception flag
      sres.setException(exmsg);
      

      The next issue is that in processSessionRequest(...)

      259  else {
      260    if (SessionService.getUseInternalRequestRouting()) {
      261        // first try
      262        String hostServerID = sessionService
      263                .getCurrentHostServer(sid);
      264
      265        if (!sessionService.isLocalServer(hostServerID)) {
      266            try {
      267                return forward(Session.getSessionServiceURL(hostServerID), req);
      
      • The NPE due to previous bug and so the previous OPENAM-8910 may help but we should handle Session.getSessionServiceURL(hostServerID) outside the forward(). Should refactor Session.getSessionServiceURL(hostServerID) so that if this has exception then should not retry or checkServerUp again and just fail. Something like
      URL srvurl = null;
      try {
          srvurl = Session.getSessionServiceURL(hostServerID);
         return forward(srvurl, req);
       } catch (SessionException se) {
         // attempt retry
         if (srvurl != null && !sessionService.checkServerUp(hostServerID)) {
      

      Lastly the the debugging session for a multi-site HA environment of this enduser indicates in ClusterStateService.java

      363    boolean checkServerUp(String serverId) {
      364        if ( (serverId == null) || (serverId.isEmpty()) ) {
      365            return false;
      366        }
      367        if (serverId.equalsIgnoreCase(localServerId)) {
      368            return true;
      369        }
      370        if ( (servers == null) || servers.isEmpty() )
      371            { return false; }
      372        StateInfo info = servers.get(serverId); <---- MAY RETURN NULL
      373        info.isUp = checkServerUp(info);
      

      So we need to guard at line 372 as info is NULL too.

        Attachments

          Issue Links

            Activity

              People

              • Assignee:
                markdr Mark de Reeper
                Reporter:
                chee-weng.chea C-Weng C
              • Votes:
                0 Vote for this issue
                Watchers:
                4 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved:

                  Time Tracking

                  Estimated:
                  Original Estimate - 2h
                  2h
                  Remaining:
                  Remaining Estimate - 2h
                  2h
                  Logged:
                  Time Spent - Not Specified
                  Not Specified