Session Handling for Gateway and Core-Service

When communicating with the gateway or core-service (rest-ws) a session is created for each request that is sent. Unless correct session handling is used, sessions will pile up and eventually hit the session limit of 1000 sessions per user (per default), This in turn will cause further requests to be denied and errors will occur on the client side. This page shows how to apply correct session handling so that sessions are reused and closed.

Opening and reusing a session

Core-Service: With each first request to the core-service containing only the Basic Auth Header, the core-service will create a new session and respond with a “SET COOKIE JSESSIONID=<ID>” header. This JSESSIONID needs to be saved and each following request should contain “JSESSIONID=<ID>” as a header to reuse this session.

Gateway: The behaviour is analogous to the core-service, no matter which authentication method is used. The only difference is that the header is called GWSESSIONID instead of JSESSIONID.

 

This represents the standard way of handling sessions via cookies as described in Using HTTP cookies - HTTP | MDN and What is JSESSIONID in Java Web application.
Current HTTP Frameworks usually support automatic handling of cookies, so you don’t have to take care of the above procedure yourself. In the Apache HTTP Components, for example, creating the HttpClient as follows suffies already:

CookieStore cookieStore = new BasicCookieStore(); CloseableHttpClient httpclient = HttpClientBuilder.create().[...].setDefaultCookieStore(cookieStore).build();

 

Closing a session

Each session has a default timeout of 30 minutes after which it is automatically closed if it is not used anymore. To explicitly close a session one of the following possiblities can be employed:

  • Gateway in version >= 8.16 LTS and Core-Service:
    The header “x-os-session-keep-alive” can be sent and set to “false”. This will close the session after the current request is completed. If the header is not sent it is automatically evaluated to the value “true” which will cause the session timeout to be reset.

  • Gateway only:
    For gateway versions >= 8.16 LTS: Call the URL <gateway>/logout . This will tell the gateway to close the session and it will return a HTTP 200 OK response.
    For gateway versions < 8.16 LTS: Call the URL <gateway>/logout?redir=/auth/info . The redir parameter is required to prevent forwarding to the login form and opening a new session again.