TRIRIGA

 View Only
Expand all | Collapse all

JSESSIONID works with TRIRIGA beta but not customer instance

  • 1.  JSESSIONID works with TRIRIGA beta but not customer instance

    Posted Mon March 13, 2023 10:13 AM
    Edited by System Test Wed March 22, 2023 11:47 AM

    We have built a server that retrieves a JSESSIONID via websignon. This JSESSIONID cookie is passed into a subsequent service call (e.g. currentUser) as a header, for authentication purposes. The flow works on TRIRIGA beta (https://beta.tririga-dev.com/)

    However, when the server is run on a customer network pointing to a customer instance of TRIRIGA, different behaviour is observed: websignon is successful and a JSESSIONID is returned (so network connectivity must be fine). BUT the subsequence service call fails with a 401 unauthorized error.

    Why is the customer TRIRIGA instance rejecting this call? Is it a specific config of their TRIRIGA instance?

    ------------------------------
    Adrian Hill
    ------------------------------

    SOLUTION: Chris hit the nail head - it appears we are hitting two Tririga instances behind a load balancer. The load balancer is doing 'round robin' which is why the second request fails (hitting a different tririga instance). A third request is successful as it hits the original tririga instance.


    #AssetandFacilitiesManagement
    #TRIRIGA


  • 2.  RE: JSESSIONID works with TRIRIGA beta but not customer instance
    Best Answer

    Posted Mon March 13, 2023 10:49 AM
    Hey Adrian,

    Are you using a UI/Process server setup? behind a load balancer? Out of the box TRIRIGA will expect the HTTP requests to land on the same application instance.

    E.g login and get JSESSION from application server 1, send GET to application 2, 401 no auth. BUT if both land on app 1, should work.

    Few instances I know of handle this with sticky session cookies in the webserver (NGINX/HAPROXY) 

    Give me a shout if you need any help.

    Kindest,

    Chris Walsh



    Original Message