secureSession

secureSession() updating;

The secureSession method of the WebSession class replaces the value of the currentSession system variable with a new WebSession object that it creates. After calling this method, the receiver of this method (which should be the existing currentSession object) is invalidated and is flagged to expire.

This method is intended to be used with the JADE Forms or HTML Documents web application type. Attempting to call the secureSession method in a Web Services or REST application raises a 1068 (Feature not available in this release) exception.

You must call this method before storing any sensitive information in the session referenced by currentSession, or before any action that might privilege or authenticate the currentSession. This is necessary to prevent "Session Fixation" vulnerabilities (https://owasp.org/www-community/attacks/Session_fixation). For example, you could have a routine to handle users logging in similar to the following code fragment.

if app.checkCredentials(username, password) then
    currentSession.secureSession(); 
    currentSession.username := username;
endif;

In this example, the secureSession method is called before storing the user name of the successfully logged in user in the currentSession object.

Important Notes about Secure Sessions

After calling the secureSession method, the old session is immediately invalidated.

The WebSession object associated with the session is deleted when the timer that cleans up expired sessions is next run, which happens within the number of minutes configured as the session timeout value in the Session Timeout text box on the Web Options sheet of the Define Application dialog. If your application has no session timeout configured (that is, it is set to zero (0)), the session, as with all sessions, remains active indefinitely. It is strongly recommended that applications that call the secureSession method have a session timeout configured.

Until the object is deleted, the process license associated with the session remains in use.

Your application can handle deleting these objects, if required. If your application has no configured timeout, your application must remove sessions itself. A suggested way of doing this, shown in the following example, is to reimplement the WebSession class processRequest method to check if the active session was invalidated, and remove it if so. Invalidated sessions have their lastAccessTime and startTime properties set to null.

processRequest(httpString: String; queryString: String) updating;
begin
    inheritMethod(httpString, queryString);
epilog
    if app.isValidObject(self) and self.lastAccessTime = null and 
    self.startTime = null then
        self.removeSessionWithMessage("Invalidated session");
    endif;
end;

Your application may need different handling, depending on how it makes use of its WebSession subclass.

2022.0.03 and higher