iPortal configuration file description

Feedback


SuperMap iPortal's main configuration information is located in WEB-INF ([SuperMap iPortal installation directory]\webapps\iportal\WEB-INF) directory, for more information about catalog description please refer to The catalog description after installation.

iPortal Configuration File Introduction

iPortal Configuration files include two parts: configuration files of portal functions and basic configuration files the same as used by iServer (For information about basic configuration files, see: Introduction to iServer configuration files ).

The former files show as the following table:

Configuration files of portal functions

File Name Description
iportal.xml The main configuration information of the iPortal, including the configuration of the database and portal functions.
iportal-monitor.xml Node monitoring configuration information, including configuring the database for storing monitoring data, and the iServer node information. For details, see: Monitoring Configuration.

iportal-storage.xml

Configuring the storage for uploaded data. Details, see: Hosted Data Storage Configuration.

iportal-ehcache.xml

The sharing settings of the cache of the proxied service access permission. The cache is saved locally by default, no need to configure. When you are configuring high availability structure for iPortal, see: How to share the cache of the proxied service access permission.

iPortal configuration file structure

The root node <IportalConfig> of iportal.xml currently contains:

Before starting SuperMap iPortal service, it is recommended that you read the following configuration file instructions carefully so that you can configure your product according to your business needs.

1. <dataSourceConnectionPoolInfo>

Used to set the SuperMap iPortal database connection pool, the default sql configuration is SQLite database. It's recommended to use the MySQL/Oracle/PostgreSQL database.

2. <uploadSetting>

3. <serviceSetting>

4. <serviceCheckSetting>

Used to set how often to detect the status of the original services, which has been registered in iPortal. If there are services changed, for example, paused, or stopped, or deleted, iPortal will synchromize the state of these services. Unit is in minutes.

5. <serviceAuditSetting>

6. <registerSetting>

7. <loginSetting>

8. <shareSetting>

9. <mapsSetting>

10. <serviceProxy>

Used to set whether the service registered in iPortal use a proxy. By default, the built-in service proxy is enabled.

If the service proxy is disabled, the following safety issue exists:

User A registered a service and shared it with user B, now user B can access the service information and knows the service address. Then user A wants to change the sharing scope to exclude user B. After user A modified the sharing settings of the service, now user B can not see the service in the shared service list, but he still can access the service because he has already known the service address.

While if the service proxy is enabled, only the registrant of the service and administrators can see the original service address, the other users who have access to the service can only see the proxied service address, thus the access control of the registration service is implemented at the portal level.

    The Redis cache configuration is provided by way of comments as follows:

Note

11. <customDirectorySetting>

Whether to enable the custom directory function. The resource types that support the custom directory function are: map (MAP), service (SERVICE), data (DATA), scene (SCENE), project (APP), insight (INSIGHTS). The default value is false, i.e., the custom directory is not displayed. You can enable the custom directory function for certain types of resources. For more information about custom directory configuration, see: Custom directory configuration.

12. <defaultInternetBuildinMapSetting>

13. <httpHeaderSetting> (Deprecated)

Used to set up domains that allow access to iPortal resources. From iPortal 9D(2019) and later versions, this item doesn't work any longer. iPortal supports all cross-domain access by default. If you need to limit the domains that can be accessed, modify the default "*" (which means support for all domain access) of the cors.allowed.origins in the %SuperMap iPortal_HOME%\webapp\iportal\WEB-INF\web.xml file to the specified accessible domains. If you want to carry cookies during cross-domain access, you also need to set the value of cors.support.credentials to true.

14. <departmentSetting>

15. <mapApps>

Map App collection. Used to configure the Map App used in iPortal for making maps. Default value is mapViewer_v2, ie., using iPortal built-in V2 version (new version) DataViz APP.

16. <groupSetting>

Configure to show or hide the function of group-related information displayed on the "My application" and "My authorization" pages. Default: true.

17.<portalCustomSetting>

Portal custom settings.

18.<mapViewerSetting>

Used to set the maximum allowed vector features to be added on Map when making maps with DataViz. Defaults to 3000.

19.<cookieStorage>

Cookie storage configuration of the logged-in user, used for session sharing between iPortal and proxy service. iPortal offers two types of caching methods: Ehcache caching and Redis caching. The system uses Ehcache cache by default, so you can use it without any configuration. The built-in service proxy supports Ehcache and Redis cache, while the independent service proxy only supports Redis cache.

    The Redis cache configuration is provided by way of comments as follows:

20.<appsConfig>

Used to set the usage rights of the WebApps built into iPortal.

21.<proxyUriRuleConfig>

 Used to configure the SSF defense for getURLResource resource.

22.<searchModuleConfig>

 Used to set the global search function of iPortal.

23.<httpsConfig>

 The https certificate trust setting of iPortal.

24.<keyConfig>

 The quota setting of the Resource Key in iPortal.