Config File Settings
Some settings cannot be made in the WebUI (see previous sections), mainly because they do not need to be changed or should be changed only if you understand their effects. These settings are stored in a configuration file named mobiletogetherserver.cfg, which is located by default in the application data folder (see below). You can edit the .cfg configuration file in a text editor. This section contains information about important settings that are safe for you to add/edit in the configuration file.
The location of the application data folder depends on the operating system and platform, and, by default, is as follows.
You can define server variables in the configuration file, and the values of these server variables can be called in the design via the mt-server-variables Altova XPath extension function. At runtime, the server variable could be used to get a server-side value, such as the server's name. Actions in the solution can then be designed based on the value returned by the server variable. For example, a different set of actions can be set up according to whether the server is a test server or a live server—without having to build two separate solutions for the two servers.
Data transfer and listening
These settings are in the Listen, ListenSSL, ListenAdmin, and ListenAdminSSL sections of the configuration file (see listings below).
The default timeout of the server is 10 seconds. If this is too low, you can use the timeout setting to set a higher timeout in seconds. If the timeout setting is missing or is < 1, then the default timeout of 10 seconds is used.
Size limit of data files transmitted to server
The server is set up by default to accept files that are up to 100 MB large. Larger files are rejected. If files larger than 100 MB are expected, you can increase the size limit by specifying the max_request_body_size setting in the Listen and ListenSSL sections of the configuration file. In the listing below, the file size has been increased so that the server can accept files of up to 200 MB. Note that the default value of max_request_body_size is 104857600 (100 MB)—even when the setting is not listed in the configuration file.
Content Security Policy (CSP) settings
Since MobileTogether Server returns a Content Security Policy (CSP) HTTP header each time it receives an HTTP request, CSP is enabled for MobileTogether Server. Browsers that don't support CSP will still work with MobileTogether Server. They will ignore the CSP header and default to the standard same-origin policy for web content. You can customize the CSP HTTP headers that MobileTogether Server sends by using the settings given below, which are in the Web and SSL sections.
By default, resources (such as images, audio, or video) can be loaded in a web page only from the same location as that from which the web page is served (in our case, that would be MobileTogether Server). You would not normally need to change this default behavior. However, exceptions might arise when content is hosted on a different domain (as, for example, when a MobileTogether solution is embedded in an IFrame). For such situations, you can can customize the CSP directives listed below according to your needs.
For more information about CSP, see https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP and https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy
default_src = 'self'. This is a fallback directive for the other CSP fetch directives below.
frame_src = 'self' (CSP fetch directive.) This directive's value also sets the value of the X-Frame-Options header field (see note below).
image_src = 'self' data:<URL> (CSP fetch directive.)
media_src = 'self' data:<URL> (CSP fetch directive.)
object_src = 'none' (CSP fetch directive.)
script_src = 'self' 'unsafe-inline' 'unsafe-eval' (CSP fetch directive; 'self' is default when no value is specified.)
style_src = 'self' 'unsafe-inline' 'unsafe-eval' (CSP fetch directive; 'self' is default when no value is specified.)
nosniff = 0 or 1. See the note about X-Content-Type-Options below.
referrer_policy = strict-origin-when-cross-origin. This is the default value. See the note about Referrer Policy below.
Note the following points:
•If a fetch directive is omitted, then the default_src directive is used as a fallback.
•If you want to specify that a fetch directive has more than one value, enter the values as a space-separated list. The listing above contains examples of space-separated values.
•The X-Frame-Options header can protect visitors from clickjacking attacks. A value of DENY indicates to the browser that your site may not be framed, while a value of SAMEORIGIN allows you to frame your own site. The value is automatically selected from the value of the frame_src setting. If frame_src is is set to 'self' or 'deny', then X-Frame-Options is automatically set: respectively, to SAMEORIGIN or DENY. If frame_src is set to a URI, however, then X-Frame-Options is not set.
•The X-Content-Type-Options header prevents the browser from mime-sniffing the document's content type, thereby forcing the browser to use the document's declared MIME type. This header can take only one value, nosniff. In the configuration settings, the nosniff setting can take a value of 1 (the default, which switches the value on) and 0 (which causes the header to not be sent).
•Referrer Policy: When a user clicks a link on a web page, the destination site receives information about the originating page. This information is obtained from the referrer header that is stored in the request made to the destination page. The amount of information that is stored in the referrer header is controlled by the Referrer-Policy header. Referrer-Policy is set automatically to strict-origin-when-cross-origin. You can set this header to other values if you like.
Strict Transport Security setting
If this HTTP header is returned in the response, it tells the browser to remember the server and try to connect with HTTPS automatically next time. For more information, see https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Strict-Transport-Security.
strict = 0 or 1, or is not set
Set the value suitably:
•0: the header is sent with max-age=0
•1: the header is sent with max-age=31536000 (which is 365 days)
•If no value is set, then the header is not sent in the response
Adding or overwriting HTTP(S) response headers
You can add headers to HTTP or HTTPS responses, or modify the existing headers of a response. To do this, set up an HTTP or HTTPS section in the configuration file and add the new headers you want (see listings below). Since the settings in these sections are processed subsequently to the processing of other headers, any already existing header will be modified by the settings in these sections. In each section below, the first setting is a new setting, whereas the second setting overwrites a header that is already defined.
my-new-http-header = some-value
Referrer-Policy = origin
my-new-https-header = some-value
Referrer-Policy = origin