Session Management

Although RESTful applications are ideally stateless, the ALM platform requires sessions to manage locking, client lifetime, and perform other basic tasks. Session management is performed using a cookie named QCSession.  Application Quality Management returns a QCSession cookie in response to your first authenticated REST call.

Your application should wait for the first QCSession cookie to return before allowing subsequent server calls. Failure to do so may result in your application having several sessions open. After a session is established, always pass the most recently returned QCSession cookie in the header of all actions.

Having more than one session open by an application may interfere with activities that require session-dependent functionality, such as entity locking. In addition, the overhead of opening and maintaining sessions affects server performance. 

The same session can be used to access resources of different projects in a site.

Sessions are automatically replaced with new sessions when they expire. The new session is of the same type as the expired session. If a session expires, locks and other session-dependent functionality expire with it.

An application can keep a session alive with periodic calls to the site-session resource. A QCSession cookie is returned by a POST on the site-session resource. The session type can be any application-defined string. You can create a session type for your application and specify a timeout different from the default in the POST operation on the site-session resource.

To protect from Cross-Site Request Forgery (CSRF) attacks:

• Create a session type rather than using the default.

• Send the X-XSRF-Token header with all requests. See Send X-XSRF-TOKEN header with all requests.

For REST clients, the session maximum idle timeout is governed by two site administration parameters: REST_SESSION_MAX_IDLE_TIME and SSO_EXPIRATION_TIME.

• REST_SESSION_MAX_IDLE_TIME defines the idle timeout used by REST client sessions. The default is 60 minutes.

• SSO_EXPIRATION_TIME defines the idle timeout for the SSO session used by authenticated clients, including REST clients. The default is 11 minutes.

The effective session idle timeout is determined by both values. A session cannot remain active longer than the more restrictive of the two settings.

Other types of clients can use a custom site administration parameter to set a default timeout for their client session type.

Open a session

A new session in a browser must have a client type that enforces XSRF token validation if there is already an open session in the same browser that enforces XSRF token validation. Add an X-XSRF-TOKEN header to each request with the value from the XSRF-TOKEN cookie returned by the site session creation.

Extend a session

Close a session

See also:

• Authenticate