PASOE 11.6.3 not setting jsessionid - Forum - Mobile - Progress Community

PASOE 11.6.3 not setting jsessionid

 Forum

PASOE 11.6.3 not setting jsessionid

This question is answered

Hi

We have implemented PASOE on a Windows Server 2012 R2 with OE 11.6.3. There are two instances, one using anonymous auth and one using basic auth with oehybridrealm.

Both are not returning cookie with Jsessionid in the response. Even adding a simple web page to the anon auth instance doesn't return me a JsessionID.

I don't think it is a client-side issue. From the same browser, I can use another server with PASOE instances on and JSessionID is returned in a cookie. Both using SSL.

Any ideas what could be blocking/preventing this.

Verified Answer

  • The ClientContextId is paired to the HTTP login session ( JSESSIONID  cookie ).   So when there is no login session ( as opposed to per request user authentication ) a new context id is generated to distinguish it from any client's previous request.   

    Is there a reason why you want user login sessions that span multiple client requests in your application but do not want to use the FORM model that supports that?  ( Just curious... )

    Mike J.

All Replies
  • Hi,

    Does this happen only Win Server 2012 R2 and work on other platforms ?

    Regards,

    Irfan

  • I think the issue is with switching to using oerealm-basic authentication model and web handlers instead of the REST adapter with PASOE.

    If I access the back-end business entity (HTTP GET) using the web-handler url, I get a login dialog as expected for secured resources. The HybridRealm is then used which authenticates the user and password against a user table in our database (not _user).

    I have debugged both the PASOE activate procedure and the HybridRealm class.

    When I make the request to the URL from the browser, after login dialog, I can see the activate procedure is called several times.

    The first few have the same unique id in SESSION:CURRENT-REQUEST-INFO:ClientContextId. The same value (integer) then appears in SESSION:CURRENT-REQUEST-INFO:SessionId. There is no valid client-principal object.

    After 3 or 4 iterations of the above, I see the debug message from the HybridRealm class (at the point of ValidatePassword).

    Even at this point, the CURRENT-REQUEST-INFO:ClientContextId and SessionId is the same as above.

    However immediately after the user validation, the activate procedure is called again. This time there is a valid and sealed client principal object. The SESSION:CURRENT-REQUEST-INFO:ClientContextId is 0, SESSION:CURRENT-REQUEST-INFO:SessionId remains as above and Client-Principle-Object:Session-ID is 0.

  • Everything other than getting JSESSIONID is working as expected.

    For OERealm, OERealmAuthProvider bean in Spring Security makes calls to OERealm ABL Class to verify the user details which include validating user,password and other attributes(ROLES,ENABLED,LOCKED & EXPIRED). As we make individual call for each operation, you see those many calls to activate procedure. As your configuration does not involve using a sealed CP while invoking the OERealm ABL class, your activate procedure does not get a Client-Principal object.  For basic-OERealm, the Session-id in the Client-Principal object will always be 0. It will be a non-zero value and equal to JSESSION-ID value when you perform a form authentication(any model).

    If you do a form-authentication you will see that the JSESSIONID is returned back for your first request while returning the login page and is set for the life of your client session, but it not returned back by your WebHandler.

    Will get back to you later on why we are not returning the JSESSIONID for the WebHandler. Basically, it is returning back whatever is mentioned in the WebHandler ABL Class response object and JSESSIONID is not part of it. In-case you really need it then you can add a header in your response object as below.

                 oHeader = NEW OpenEdge.Net.HTTP.HttpHeader('JSESSIONID', SESSION:CURRENT-REQUEST-INFO:SessionId).

               ASSIGN

                   oResponse:Entity        = oBody

                   oResponse:ContentType   = 'text/plain':u.

                  oResponse:SetHeader(oHeader).

    Regards,

    Irfan


  • Server login sessions (i.e. JSESSIONID) are disabled in the configuration when you use oeablSecurity-anonymous.xml or oeablSecurity-basic-oerealm.xml ( you indicates you were using basic auth with oerealm).   Both anonymous would not do a user login at all, and basic will validate the user's id & password on each client request and not start a server login session.

    Mike J.

  • Thanks for the responses. I was kind of expecting to be able to track user-logins and tie this up to activity in the Business Entity even when going via the basic auth mechanism. Even though the session spans that request only, I saw the ClientContextId being unique prior to the CP being created and sealed but then after authentication is completed and Business Entity code is executed, this unique id is lost. Will have to rework some of the code in the activate procedure as was expecting the ClientContextId to persist throughout the request.


  • The ClientContextId is paired to the HTTP login session ( JSESSIONID  cookie ).   So when there is no login session ( as opposed to per request user authentication ) a new context id is generated to distinguish it from any client's previous request.   

    Is there a reason why you want user login sessions that span multiple client requests in your application but do not want to use the FORM model that supports that?  ( Just curious... )

    Mike J.