Other Uses of the SessionControl Pattern

Introduction    Implementing    Other Uses     Parts     Example

• Ending Sessions
• Changing the Time-out Interval
• Action to Take when Different IP Addresses
• Switch off Validation of the IP Address
• Deletion of Session Records
• Define Own Error Reporting
• Display SessionID Field in Generated HTML Documents

Ending Sessions

A Session is defined as Active when it is created.  The Session can then be Timed out if no requests have occurred within a certain time interval, or it can be set to Ended by the web user, i.e. the user is actively closing the Session.

A deletion function DeleteInactiveSessions is defined in the Session library and this job may be run periodically to clean up (delete) inactive Session.  In this way, the Session library supports the complete life-cycle of a Session.

Changing the Time-out Interval

The time-out interval is used by the ValidateAndUpdateSession and the TimeOutExpiredSessions functions.

The specification of the time-out interval is externalized in the function SetTimeOutInterval scoped by the ValidateAndUpdateSession function.  The time-out interval is set to 10 minutes as default, but this interval may be overridden by assigning other values to the output fields of the function.

Action to Take when Different IP Addresses

For each web request, it is validated if the IP address of the request is the same as the IP address saved with the Session record when this was initially created.  If the two IP addresses do not match, an error status will be returned by the function.

The main reason to perform this validation is to assure that a user cannot change his Session ID to the Session ID of another web user and in this way try to get the access rights of the other user.  If the Session ID is changed like this, the IP Address validation will see an IP Address different from the IP Address stored with the new Session record and access to the web application will be denied.

In the Edit point 0 Different IP Address of the ValidateAndUpdateSession function, code can be inserted to deal with this situation.  It would not be fair just to close the Session and in this way punish an innocent user.  On the other hand, functionality may be specified to log those situations and perhaps even notify the innocent user that login attempts with a different IP Address have occurred to his Session.

Switch off Validation of the IP Address

Different IP Addresses does not necessarely mean that a malicious user is trying to log on to the application.

Using a dial-up connection, this connection may itself be timed out (independently of the Websydian application) and when the connection is re-established, it may have got a new IP Address.  As mentioned above, it could be considered what action to take when different IP Addresses occur - and this action may be to do nothing at all.

The IP Address validation can be switched off by resetting the Output<ErrorStatus> field to value OK in the 0 Different IP address Edit point of the ValidateAndUpdateSession function followed by a Go sub directly to the Update session record subroutine.

Switching off the IP address validation.

Deletion of Session Records

Deletion of Timed-out Sessions

If a direct delete of the Session records is needed in case of time-out (thus not saving timed-out sessions), it can be implemented by directly calling the DeleteRow function from the ValidateAndUpdateSession function followed by a return from the function in the 0 Before time out of session Edit point.

Or it can be implemented by replacing the calls to the TimeOutSingleSession function with calls to the DeleteRow function:

Deletion of Ended Sessions

Call the DeleteRow function directly instead of calling the EndSingleSession function.  If implementing the EndUserSession Event Handler function, its call to this EndSingleSession function must be replaced by a call to DeleteRow.

Deleting only Inactive Sessions Older than a Specified Time Difference

The DeleteInactiveSessions function can be modified to delete only records up to a specific point in time, i.e. a specific date and time.  This time difference is specified relative to the current time, e.g. current date/time minus one month.  To do this, assign the appropriate values to the Local<LastRequestDate> and the Local<LastRequestTime> fields in the 0 Set start date and time for deletion edit point.

Define Own Error Reporting

The default error message can be overridden by changing the large properties of the inherited Message objects scoped by the Abstract.EventDispatcher pattern.

In the 0 Before generation of error page edit point of the Abstract.EventDispatcher function, functionality can be added to generate alternative error messages.  This is necessary if the error messages must contain parameters from the program.  The error message is set by assigning the new message text to the Document<ErrorMessage> field.

Display SessionID Field in Generated HTML Documents

Visible SessionID fields have by default been removed from the Document Template generation and in this way making the Session handling transparent for the web user.  This has been done by declaring the SessionID field in the OmitDetailsFields and the OmitGridFields variables of the SessionControl.Abstract.PageGenerator function.

Example:

To make the SessionID field visible again to the web user through the generated Document Templates, the following omit-declarations must be specified:

In the example above, it is assumed that the MySession entity inherits from the SessionControl pattern and that all Page Generators in the application inherit from the abstract Session Page Generator.

The triple-declarations above will cause the SessionID field to be visible on all generated Document Templates.

Visible SessionID fields in this example of a generated HTML Document Template.  The fields would by default be omitted from the generated Details and Grid HTML tables.