Provides basic connection settings for the internal web server, like HTTP and HTTPS connections.

It is possible to configure the HTTP and/or HTTPS connection to the internal web server. For testing purposes of HTTPS connections, a self-signed certificate can be generated before purchasing one from a provider.

The connections to be created at server startup can be HTTP and/or HTTPS. HTTP is the default connection, covering most scenarios. HTTPS transfers the data via an encrypted connection. Both connections can be used in parallel.

• Default value: HTTP

With the default configuration, the server is available from all IP addresses of the system. If the server should only listen on a defined IP address or hostname, it can be specified in this property. After a restart, the server will only be available at the stored IP address or hostname.

Using the Context option, the i-net HelpDesk server is being run below the given path. It allows running the server alongside other applications on the same server URL - similar to application servers.

Note: The context given has to start with a / and must not end with a /.

Note: Setting a different context will disable Let's Encrypt certificate retrieval. This is due to Let's Encrypts nature to check for the /.well-known/acme-challenge response at the servers root.

The internal web server is listening on the specified port.

Note: the server port can also be set using the environment variable inet_http_port. This way the server can be started in a dynamic way where the platform provides a specific port, e.g. Heroku.

The internal web server is listening on the specified port for encrypted requests.

Note: the server port can also be set using the environment variable inet_https_port. This way the server can be started in a dynamic way where the platform provides a specific port, e.g. Heroku.

All unencrypted requests on the standard HTTP port are forwarded to HTTPS. This option is available only if the default ports (80 for HTTP, 443 for HTTPS) are used.

To use HTTPS connections, a certificate must be provided. Normally, you can purchase one from a provider like Thawte or VeriSign. For testing purposes, a self-signed HTTPS certificate can be created.

Some browsers and applications need all intermediate certificates of the chain. The certificates also have to be saved in the certificate file. With the PEM Format (Base64) you can do this with a text editor.

In addition to the certificate, the corresponding private key is required to read the encrypted requests. Your SSL certificate provider will also send you this key. Often it's a file with the extension ".key" or is part of the ".pem" file.

Private keys can be stored in PKCS8, X509 or PEM format.

Note: the private key must not have a password set.

The URL given here will be used throughout the system to make absolute links in, e.g. emails work. The URL is determined using the hostname by default. This property does not change the URL at which the server listens.

The external visible URL must be used if the i-net HelpDesk server is behind a reverse proxy.

Note: The proxy URL should be provided here in a cloud-based environment.

Note: The URL may be relevant for the licensing process and should be provided correctly - so that the start page of the server can be reached using the address. The protocol, FQDN, port and an application server context can be used for the URL

Settings limiting the amount of concurrent requests to speed up the internal web server.

The maximum queue length for incoming socket connection indications (i.e. connection requests). If the maximum value has been reached, further connection requests will be refused.

• Default value: 500

The number of concurrent HTTP requests accepted and handled by the server. Further requests are queued.

• Default value: 250

Maximum heap memory for the server process. The default value is 1/4 of the RAM (for 32-bit operating systems the default value is 256 MB). The specified value should not be greater than the free RAM as the swap file usage greatly reduces the performance.

The server language will be used to display error messages in the correct language. This property corresponds to the Java VM property: -Duser.language.

• Default value: System setting of the operating system

The server country will be used to format currency values in the used language. This property corresponds to the Java VM property: -Duser.country.

• Default value: System setting of the operating system

This will be passed directly to the VM as an argument.

• Default value: Empty
• Example: -javaagent:c:\path\to\your\javaagent.jar

If necessary, then it is possible to restart the server in this section. Please note that all unsaved changes will be lost. It could occur that the configuration manager can not reconnect to the server because of changed web server port or modified restrictions for the current user.

Some security settings

Modifies the SameSite attribute of the Set-Cookie HTTP response header. More information about the SameSite Cookie can be found here: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Set-Cookie/SameSite

Note: Using the value None requires that the browsers access the i-net HelpDesk server using an HTTPS connection. The login via HTTP is no longer available. If, due to a miss-configuration of the HTTPS access, a login is no longer possible, you have to start the Recovery Manager to resolve the issue.

Note: If you're using the OAuth authentication provider, you either use Lax or add the provider's OAuth URL to the Allowed Cross Origins

Frame embeddings using the X-Frame-Options header field can be set up with this configuration property. The supported values are:

• Always allowed: The header is not set
• Deny: The header is set to DENY and frame embedding of the applications is not allowed
• Same Origin: The header is set to SAMEORIGIN and allows embedding the application only from the same origin address.

Enables the Cross-Origin Resource Sharing (CORS) checks. If a value is entered in these fields (see below) it will send the Access-Control-Allow-Origin to browsers containing:

1. the values from this field and
2. the public visible URL

The header entry will make sure the browser adheres to the CORS rules. Additionally, the server will also check for that it is addressed with any of the given values. That means that you cannot can the servers interface with any other addresses as configured by the public visible URL or any of the values in the Allowed Origins field.

*

or

https://foo.example.com, http://bar.example.com:9000

or

*.example.com

This options empowers you to tailor the content of the crossdomain.xml file of this server. The crossdomain.xml file governs how other domains and sources can interact with the user's web content. You can define rules and permissions in the crossdomain.xml file to specify which external domains are permitted to access data or resources on this server. This customization ensures controlled and secure cross-domain interactions, safeguarding sensitive information and enhancing the overall security posture of this server.

The robots.txt option allows customizing the content of the respective file in the root of this server. The robots.txt file instructs search engine bots and other automated tools on which parts of the site to crawl and which to avoid. You can specify rules using directives like "User-agent," "Disallow," and "Allow" to control the indexing and visibility of their site's content in search results. This customization helps manage how bots interact with the website and maintain data privacy.

The security.txt configuration enables you to define the content of the /.well-known/security.txt file of this server. The security.txt file serves as a standardized method for organizations to communicate their security contact information and vulnerability disclosure policies. With this configuration, users can specify how security-related matters should be reported and addressed, including contact details and preferred communication channels. By tailoring the security.txt content, you can streamline the reporting process for security researchers and ethical hackers, fostering a more secure online environment.

There are two advanced sections, one for additional HTTP and one for HTTPS headers, that can be sent along every response data. This allows to send, e.g. HSTS responses. It is advisable to prefix custom headers with X- to differentiate them from headers of the standard protocol.

Note: Headers that may be interesting for setting up HSTS are documented in the Reverse Proxy configuration. If you are not using a reverse proxy, you can set these headers here as well.

Note: This feature has to be handled with care to not make server responses unusable by the web client.