Recorded session access request options
You can control how users can access recorded sessions by setting options, globally or per policy. Some options can be overridden by the user when issuing their requests.
The following options are located on the Recorded session access request tab :
Option | Description |
|---|---|
SMON DEFAULT REQ PACKAGE LIFE | The number of days before a generated package is deleted. This value can be overridden per request. The default value is 7. |
SMON DEFAULT REQ PACKAGE LIFE MAX | The maximum number of days a package will remain available. The default value is 30. |
SMON DEFAULT REQ SESSION ACTIVE BEGIN | Search for sessions active starting this number of days relative to the day the request is issued, where a negative number represent days before the request is issued and a positive number represent days after the request was issued. This value can be overridden per request. The default value is -30. |
SMON DEFAULT REQ SESSION ACTIVE END | Search for sessions active until this number of days relative to the day the request is issued, where a negative number represents days before the request is issued and a positive number represents days after the request was issued. This value can be overridden per request. The default value is 0. |
SMON DEFAULT REQ SESSION ACTIVE MAX | The maximum range (in days) of recorded sessions the user will be able to search. The default is 200. |
SMON DEFAULT REQ SESSION BROWSER VIEW BEGIN | The user can start viewing the recorded session this number of days relative to the day the request is issued. This value can be overridden per request. The default value is 0. |
SMON DEFAULT REQ SESSION BROWSER VIEW END | The user can view the recorded session until this number of days relative to the day the request is issued. This value can be overridden per request. The default value is 7. |
SMON DEFAULT REQ SESSION BROWSER VIEW MAX | The maximum range (in days) a recorded session can be viewed. The default is 31. |
SMON DEFAULT REQ SESSION SEARCH BEGIN | The user can start searching this number of days relative to the day the request is issued. This value can be overridden per request. The default is 0. |
SMON DEFAULT REQ SESSION SEARCH END | The user can search until this number of days relative to the day the request is issued. This value can be overridden per request. The default is 7. |
SMON DEFAULT REQ SESSION SEARCH MAX | The maximum duration (in days) the user will be able to search. The default is 31. |
See also
Session monitor app to learn how to set options for the storage of recorded data, and other module behavior.
Profile and Request Attributes for information about built-in attributes related to requests for recorded session data.
Cross-origin resource sharing for session recording
When an auditor or someone with appropriate privileges requests a session recording package, the package is stored in the SMON PACKAGE STORAGE PATH on the Bravura Security Fabric server where that auditor's WebUI session is running. When that created package is downloaded during a WebUI session connected to other servers, Cross-origin resource sharing (CORS) must be configured in order for the downloader's browser to allow retrieval of the compiled video or recording archive. You configure CORS by listing ALLOWED ORIGINS (Manage the system > Maintenance > System variables). Enter a comma-separated list of node-specific URLs of all the user-accessible nodes (see example below).
CORS blocks the retrieval operation -- the HTTP(s) request going to a different server than the one where the rest of the current WebUI is rendered. It is not required for search, nor for viewing recorded session metadata that's loaded in the backend database tables after the session is closed and processed by smonprocessmeta .
The following is an example of the process in detail:
The auditor wanting to request a package connects to the application URL.
The load balancer sends them to one node (server1).
The user session is created on that node and a well-configured load balancer keeps all HTTP requests from that session going to that same server1 node.
SMON HTTP URL can be configured so that session monitoring files go to a dedicated application node, or via a separate load balancer, to a subset of dedicated nodes not encumbered by automation or by processing user sessions.
If that's not the case, and session recording is using the same load balancer that the users and application administrators WebUI use, review the settings required for the load balancer to send all recorded remote session data to the same application node that is rendering the user's WebUI session.
The auditor requests a session recording package.
The package is written on that server at the SMON PACKAGE STORAGE PATH.
The path has to be available on every node exactly the same, including the drive letter, even if the actual storage location is different; for example, different directories of the same Network Attached Storage (NAS) or Storage Area Network (SAN) can be mounted to the same location on every application node:
SAN has directory server1\packages\ mapped as S:/privilege/packages/ on the node whose hostname is server1.
The same SAN has directory server2\packages\ mapped as S:/privilege/packages/ on the node whose hostname is server2.
In this case SMON PACKAGE STORAGE PATH can be S:/p rivilege/packages /.
When a downloader user connects from another workstation, the load balancer can place their session on another node (server2) and keep it serving from there.
In order for the packages to be accessible for download from server2, the CORS setting has to allow users' browsers to collect resources from the node-specific URLs of all the user-accessible nodes.
In the case described above, that value would be:
https://server1.domain.com/,https://server2.domain.com/