Source string Read only

46/460
Context English State
Whitelisting Additional Origins in the Security Headers
If you now try to access the external interface application, you will be able to verify that the scripts are included in the code. However, your browser will probably block access to all *inline* and *external* resources, therefore the code might fail with some errors.
This behavior is by design, since external resources can only be loaded if they are specifically whitelisted in the *Content Security Policy* headers.
To check for blocked code, please use suitable web browser inspection tools. In our example, we will be using Mozilla Firefox and its web console available via *Tools → Web Developer → Web Console* menu item, or via the *F12* shortcut key.
For the example code snippet, you might receive following errors in the console when the application is accessed:
Browser Console Errors and Warnings
From the console errors we can see that the external script resource was prevented from being loaded (lines 1 and 3). In addition to that, two evaluation calls were also blocked (lines 2 and 5). All errors reference a *Content Security Policy* rule under the name of ``script-src``, which signals script resources.
We need to add both the external resource and the evaluation calls to the additional origins list of the *Content Security Policy* headers:
Search for the setting ``WebApp::Server::AdditionalOrigins``.
In case a value for ``script-src`` is already present, click on the plus button next to it. Otherwise, proceed below.
Enter the domain part only of the blocked resource in the text field. For example: ``https://www.example.com``. This allows the external resource to be loaded.
Click on the plus button next to the field, so another value is added.
Enter the following directive in the new field, including the quotes: ``'unsafe-eval'``. This allows the evaluation calls to be executed.
There is no need to rebuild the external interface application at this point, as the additional origins configuration should be immediately in effect.
If you reload the external interface application, you might get some additional errors. In our example, it might be the following:
Additional Browser Console Errors and Warnings
This error points that an additional resource that was also blocked, an image at a specific location (line 1). We can deduce this via the name of the *Content Security Policy* rule ``img-src``, which references an image resource. In order to add it to the whitelist, try the following:
In case a value for ``img-src`` is already present, click on the plus button next to it. Otherwise, proceed below.
Enter the domain part only of the blocked resource in the text field. For example: ``https://www.example.com``. This allows the external image resource to be loaded.
Try again to reload the external interface application and check if there are more errors. If not, your scripts are now probably working as expected.
Unfortunately, it is not possible to predict what kind of resources your scripts might be requiring. But, no worries, you can whitelist most of them, just make sure to follow the trail of hints shown in the browser console log. Find a corresponding header rule in the configuration and update it accordingly.
Some resources might only be requested by others, hence several iterations might be needed until everything is configured properly.
Whitelisting external resources opens potential security risks in your OTRS application! Only allow those resources that you are sure are not malicious and come from reputable sources. Keep in mind that if something is secure today, does not mean it will be tomorrow. Stay safe!
Cookies and Local Storage
The applications need cookies and local storage for proper working. Both the cookie and the local storage are stored on the user’s computer. This storage does not include personal data, they are only needed for the operation of the application.
The only cookie stored when the user visits the external interface is ``AuthenticationCustomer``. This cookie stores the session ID of the logged in customer user and has a lifetime of 16 hours.
Additionally, the following key-value pairs are stored in the web browser’s local storage:
The UUID values in the local storage are auto-generated when the user visits the external interface for the first time. The local storage has no expiration date and stores data used for the application itself.
Glossary
Activity
Part of the process management.

Loading…

User avatar None

New source string

OTRS 7 / Administration ManualEnglish

New source string a year ago
Browse all component changes

Glossary

English English
No related strings found in the glossary.

Source information

Flags
read-only
Source string location
../../content/external-interface/layout.rst:176
String age
a year ago
Source string age
a year ago
Translation file
locale/content.pot, string 1041