This documentation website is no longer maintained. Click here to go to the latest documentation.

Support
Release Notes
Resources

Standard Form Space Properties

   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.

Cache Headers

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

CORS Headers

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.

Security Headers

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.

System Wide Settings

  1. Log in to Manager as a Global Administrator.
  2. Select Services > All Services.
  3. Select Form Submission Access Controller from the Type dropdown list. There should only be one item of this type.
  4. Click the service and select the Parameters Edit tab.
  5. Modify a CSP in the Form CSP Header Value field as required and click Save. For more information, see configure service parameters edit.

Organization Level Settings

The Organization CSP header limit is 2 KB.  |   21.11 This feature was updated in 21.11.

  1. Log in to Manager as an Organization Administrator.
  2. Select Forms > Organizations.
  3. Find your organization and select the Security tab.
  4. Under Forms Content Security Policy (CSP), select the Override System Defaults checkbox and click Save.
  5. Modify the value of Organization CSP Header as required and click Save . For more information, see configure organization security.

LinkedIn Example

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.

X-Frame-Options

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:

  • NONE
  • SAMEORIGIN - the page can only be displayed in a frame on the same origin as the page itself.
  • ALLOW-FROM URI - the page can only be displayed in a frame on the specified origin, for example www.example.com.
  • blank - no X-Frame-Options header will be set.

Next, learn how to configure form space properties.