Journey Manager (JM) Previously known as Transact Manager (TM). | System Manager / DevOps | 21.11 This feature was updated in 21.11.
Each form space has a number of predefined properties that allow you to customize a form space without any extra development efforts. For example, you can easily improve form space access security by using the CORs headers. Manager allows you to edit properties, if additional customization is required.
Some properties are straight-forward but some require more understanding, so they are listed below.
The cache HTTP header value to set if defined.
Pragma: no-cache
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0, private
Expires: 1
The Cross-Origin-Resource-SharingCross-Origin Resource Sharing (CORS) is a mechanism that uses additional HTTP headers to tell a browser to let a web application running at one origin (domain) have permission to access selected resources from a server at a different origin. A web application executes a cross-origin HTTP request when it requests a resource that has a different origin (domain, protocol, and port) than its own origin. (CORS) security HTTP header values allow you to set the Access-Control-Allow-Origin header on the API calls to enable applications such as Open UXOpen UX is the open API for development of financial customer journeys on the Temenos Journey platform. Teams skilled in use of React, Angular or other Javascript frameworks will find this the fastest path to developing production class applications. to be able to support the calls. The CORSApprovedOrigins
list defines the approved origins, which will be validated against the origin on a request and, if it matches the ${request-origin}
, it will be replaced with the provided origin. | 19.05
This feature was introduced in 19.05.
The example of CORS configuration is shown below:
{
"ApplyCORSHeaders":"true",
"CORSApprovedOrigins":"test-cors.org,avoka.com,temenos.com",
"ExcludedCORSPaths":"/secure/servlet,/app,/secure/app/cache",
"CORS_HEADERS":{
"Access-Control-Allow-Origin":"${request-origin}",
"Access-Control-Allow-Methods":"POST, PUT, GET, DELETE",
"Access-Control-Allow-Credentials":"true",
"Access-Control-Max-Age":"86400"
}
}
For more information on CORS and how it works, see https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS.
The Content Security PolicyContent Security Policy (CSP) is a computer security standard introduced to prevent cross-site scripting (XSS), clickjacking and other code injection attacks resulting from execution of malicious content in the trusted web page context. CSP provides a standard method for website owners to declare approved origins of content that browsers should be allowed to load on that website—covered types are JavaScript, CSS, HTML frames, web workers, fonts, images, embeddable objects such as Java applets, ActiveX, audio and video files, and other HTML5 features. For more information, see https://www.w3.org/TR/CSP/ (CSP) security HTTP header improves overall forms' security. It is applied to all form's resources that are passed via each form space. If it is not set, the Form CSP Header Value parameter of the Form Submission Access Controller server is used as the default. | 18.11 This feature was introduced in 18.11.
The CSP response header helps you reduce XSS risks on modern browsers by declaring what dynamic resources are allowed to load via a HTTP Header, thereby protecting your solution from a range of vulnerability attacks.
The example of the CSP response header is shown below:
Content-Security-Policy: script-src 'self' 'unsafe-eval'; object-src 'none'; connect-src 'self'
X-Frame-Opticns: SAMEORIGIN
X-Content-Type-Options: nosniff
X-XSS-Prctection: l; mode=block
By default, Manager has strict CSP settings configured. Occasionally, you need to include a capability or 3rd party service in your forms that require changes to the default CSP settings. You can configure the following settings in Manager in order to allow your solution to operate as expected yet still maintain a strong CSP configuration.
The Organization CSP header limit is 2 KB. | 21.11 This feature was updated in 21.11.
The LinkedIn SDK requires a JavaScript library to be loaded from their remote server. The default CSP settings are usually something like
script-src 'self'; object-src 'none'
These settings permit scripts to be loaded from the same server, but no other. To permit the remote LinkedIn JavaScript file to load we must modify these setting to allow JavaScript sources from the relevant LinkedIn domains as follows:
script-src 'self' https://platform.linkedin.com https://www.linkedin.com 'unsafe-inline'; object-src 'none';
Due to the way the LinkedIn integration uses inline JavaScript we need to add the 'unsafe-inline' directive.
Note that when we relax these settings, we are only adding known and trusted domains to the configuration, as opposed to using wildcards which could compromise this security layer.
The X-Frame-OptionsX-Frame-Options HTTP response header can be used to indicate whether or not a browser should be allowed to render a page in a <frame>, <iframe>, <embed> or <object> . Sites can use this to avoid clickjacking attacks, by ensuring that their content is not embedded into other sites. HTTP header improves overall forms' security. It is applied to all form's resources that are passed via each form space. The X-Frame-Options include:
Next, learn how to configure form space properties.