Advanced settings

The following parameters can be changed in the configuration.

security.ssl.trustAny: This parameter enables support for self-signed certificates for HTTPS connections. By default the function is disabled (false).
security.login.redirect.trusted.hosts: Comma-separated list of accepted hostnames. This list defines redirection destinations accepted if the map.apps login process is using redirects to forward the client to a specific site after successful login. This ensures that users are protected from attackers who intend to redirect them to a malicious site.

Adding hostnames to this property is only required in special situations, for example if applications are integrated with map.apps login that are deployed on a different host. This often occurs while using development projects.

Wildcards can also be used to achieve trust on a domain basis.

Example: *.gishost.org
Default: localhost
security.embedding.allowed.origins: Comma-separated list of origins that can embed map.apps in an iFrame. If the embedding page is not allowed, the responses to the X-Frame-Options: DENY header request are added.

If the embedding page has the same origin as the app to be embedded, this is allowed and the X-Frame-Options: SAMEORIGIN header is set.

Example: security.embedding.allowed.origins=https://my‑example.com:8080,https://demos.de

Default: <empty>

Providing User Specific Bundles and Widgets

The following only applies to applications stored in the file system, without using map.apps Manager. In addition, map.apps must be linked to security.manager or map.apps Usermanagement.

Take the following steps to provide role based bundles and widgets (can be used for tools as well).

At first, configure an app in map.apps Manager and export it. Afterwards the extracted app has to be placed in the following folder: {map.apps dir}\js\apps\YourApp. It might be necessary to create the subfolder apps/ manually. The file app.json has to be renamed to app.jsp.

It is possible to use a security.manager library to filter app configuration files. This technique uses the security.manager tag library and requires to define a JSP file (app.jsp) instead of a JSON file (app.json). Despite a special header, the content definition of the files is similar. When the file is requested from the server, it is transformed into a JSON file without the additional header. Within the JSP file, special tags can be used to filter certain content, based on the user’s role.

Example

 <s:isInRole role="myRole">"selection"</s:isInRole>

In this example the "selection"-string is only added to the file if the current user has the role "myRole". This tag can be used at any position in the file, for example to exclude bundles in the "allowedBundles" section or to exclude certain tools from a toolset definition.

Sample of an app.jsp file

 <%@ page contentType="application/json; charset=UTF-8" pageEncoding="UTF-8" language="java" session="false" isThreadSafe="true" isELIgnored="true"%><%@ taglib uri="https://www.conterra.de/security/tags" prefix="s"%>{
   "load": {
     "allowedBundles": [
       "system",
       "map",
       "themes",
       "templates",
       "templatelayout",
       "windowmanager",
       "coordinatetransformer",
       "resultcenter",
       "contentviewer",
       <s:isInRole role="sM_Administrator">"selection",</s:isInRole>
       "infoviewer",
       "toolset",
       "toolrules",
       "authentication"
     ]
   },
   "bundles": {
     ...
   }
 }

To transform the content of the jsp file to a JSON file, it is necessary to create a reference to the file in the configuration and to add it to the list of protectedAnonymousResources.

 ...
 security.application.jspMappings=.......,/js/apps/{YourApp}/app.json

 security.application.protectedAnonymousResources=/js/sample/,/js/sample/*.html,**/appauthorization/app.json,**/{YourApp}/app.json
 ...