Ermöglicht grundlegende Verbindungseinstellungen für den internen Webserver, wie HTTP und HTTPS Verbindungen.
Der interne Webserver ermöglicht das Konfigurieren von HTTP und HTTPS Verbindungen. Zu Testzwecken von gesicherten HTTPS Verbindungen, kann ein selbst signiertes Zertifikat vom Server erstellt werden, bevor welche von einem Anbieter erworben werden.
Es kann gewählt werden, welche Verbindungen der Server beim Starten erzeugt und zugreifbar macht. HTTP-Verbindungen sind der Standard und für die häufigsten Szenarien ausreichend. HTTPS hingegen überträgt alle Daten verschlüsselt. Es können beide Verbindungen gleichzeitig genutzt werden.
In der Standardkonfiguration ist der Server auf allen verfügbaren IP-Adressen ansprechbar. Sobald man die Verfügbarkeit auf eine spezielle IP-Adresse oder Hostnamen beschränken möchten kann man diese Wert entsprechend angeben. Nach dem Neustart ist der interne Webserver nur noch über die angegebene IP-Adresse bzw. Hostnamen erreichbar.
Mit der Context-Option wird der INETAPP-Server unter dem angegebenen Pfad ausgeführt. Sie ermöglicht es, den Server neben anderen Anwendungen mit der gleichen Server-URL laufen zu lassen - ähnlich wie bei Anwendungsservern.
Hinweis: Der angegebene Context muss mit einem /
beginnen und darf nicht mit einem /
enden.
Hinweis: Mit dem Einstellen eines anderen Context wird der Abruf von Let's Encrypt-Zertifikaten deaktiviert, da Let's Encrypt die Challenge-Antwort im Verzeichnis /.well-known/acme-challenge
, vom Stammverzeichnis des Servers aus gesehen, aufruft.
Die Serveranwendung lauscht auf dem angegebenen Port auf neue Berichtsanfragen.
Die Serveranwendung lauscht für verschlüsselte Anfragen auf dem angegebenen Port auf neue Berichtsanfragen.
Alle unverschlüsselten Anfragen auf dem Standard HTTP Port werden auf auf HTTPS weitergeleitet. Diese Option ist nur verfügbar, wenn die Standard Ports (80 für HTTP, 443 für HTTPS) genutzt werden.
Für Testzwecke kann ein eigenes benutzerdefiniertes Zertifikat erstellt werden. Außerdem ist es möglich, ein Zertifikat von der Zertifizierungsstelle Let’s Encrypt anzufordern.
Um die HTTPS Verbindung nutzen zu können, ist die Bereitstellung eines Zertifikats notwendig. Dieses erhalten Sie von einem entsprechenden Anbieter wie Thawte oder VeriSign. Um die verschlüsselte Verbindung vorher zu testen, kann ein selbstsigniertes HTTPS Zertifikat erstellt werden.
Einige Browsers und Applikationen benötigen auch alle Zwischenzertifikate der Zertifizierungskette. Dafür müssen diese mit im Zertifikat gespeichert sein. Beim PEM Format (Base64) kann dies mit einem Texteditor hintereinander gespeichert werden.
Zusätzlich zum Zertifikat wird der private Schlüssel benötigt, um die verschlüsselten Anfragen lesen zu können. Diesen Schlüssel erhalten Sie ebenso vom Anbieter des Zertifikats. Oft handelt es sich um eine extra ".key" Datei oder ist Teil der ".pem" Datei.
Private Schlüssel können im Format PKCS8, X509 oder PEM gespeichert sein.
Hinweis: Für den privaten Schlüssel darf kein Passwort gesetzt sein.
Die hier eingestellt Adresse wird im System verwendet um Verlinkungen, zum Beispiel. in Emails korrekt zu erzeugen. Sie wird für den Standardwert aus dem Hostnamen erzeugt. Diese Eigenschaft ändert nicht die URL, auf der der Server zur Verfügung steht.
Die externe sichtbare URL muss verwendet werden, wenn sich der INETAPP-Server hinter einen Reverse Proxy befindet.
Hinweis: In einer Cloud-basierten Umgebung wird hier die Adresse des Proxy-Server eingetragen.
Hinweis: Die URL kann für die Lizenzierung relevant sein und sollte daher auf den korrekten Wert für den Zugriff auf den Server eingestellt werden - die Startseite des Server sollte darüber erreichbar sein. Hier sind sowohl die Angabe des Protokolls, FQDN, Port und Application Server Kontext erlaubt.
Einstellungen, welche die Anzahl gleichzeitiger Anfragen begrenzen, um den internen Webserver zu beschleunigen.
Dieser Wert gibt die maximale Länge der Queue für ankommende Socket-Verbindungen an (z.B. Verbindungsanfragen). Ist der Maximumwert erreicht, wird jede weitere Verbindung abgewiesen.
Dies ist die Anzahl der gleichzeitigen HTTP-Anfragen die vom Server angenommen und bearbeitet werden. Weitere Anfragen werden eingereiht.
Maximaler Heap Speicher für den Server Prozess. Der Standardwert beträgt 1/4 des installierten Arbeitsspeichers (bei 32 Bit Betriebssystemen liegt er bei 256 MB). Der angegebene Wert sollte nicht größer sein als der freie Arbeitsspeicher, da die Nutzung der Auslagerungsdatei die Performance stark reduziert.
Die Sprache des Servers wird für die Ausgabe von Fehlermeldungen verwendet. Diese Eigenschaft entspricht dem Java VM Parameter: -Duser.language.
Das Land des Servers wird für die Währungsformatierung verwendet. Diese Eigenschaft entspricht dem Java VM Parameter: -Duser.country.
Dies wird direkt an die Java VM als Argument weitergeleitet.
-javaagent:c:\path\to\your\javaagent.jar
Wenn es erforderlich sein sollte, kann man den Server hier neu starten. Beachten Sie dabei bitte, dass ungespeicherte Änderungen verloren gehen. Unter Umständen kann sich der Konfigurationsmanager anschließend nicht erneut mit dem Server verbinden. Das kann beispielsweise auftreten, wenn der Port des internen Webservers oder die Zugriffsrechte des aktuellen Benutzers geändert wurden.
Einige Sicherheitseinstellungen
Ändert das Attribut SameSite
des HTTP-Antwort-Headers Set-Cookie
. Weitere Informationen zum SameSite-Cookie finden Sie hier: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Set-Cookie/SameSite
Hinweis: Die Verwendung des Wertes None
erfordert, dass der Browser über eine HTTPS-Verbindung auf den INETAPP-Server zugreift. Die Anmeldung über HTTP ist nicht mehr möglich. Wenn aufgrund einer Fehlkonfiguration des HTTPS-Zugriffs eine Anmeldung nicht mehr möglich ist, müssen Sie den Recovery Manager starten, um das Problem zu beheben.
Note: Bei der Verwendung eines OAuth-Authentifizierungsanbieters, muss entweder Lax
verwendet werden oder die OAuth-URL des Anbieters zu den Erlaubte Cross Origins hinzugefügt werden.
Aktiviert die Cross-Origin Resource Sharing (CORS) Prüfungen. Ist ein Wert in diesem Feld eingegeben (siehe unten), dann wird der Access-Control-Allow-Origin
-Header an den Browser gesendet und enthält die folgenden Werte:
Der Header-Eintrag stellt sicher, dass sich der Browser an die CORS-Regeln hält. Zusätzlich prüft der Server auch, ob er mit einem der angegebenen Werte angesprochen wird. Das bedeutet, dass Sie die Web-Oberfläche des Servers nicht mit anderen Adressen ansprechen können, als mit der öffentlich sichtbaren URL oder einem der Werte im Feld Erlaubte Origins.
*
oder
http://foo.example.com, http://bar.example:9000
oder
*.example.com
Der Inhalt der Datei crossdomain.xml in der Root.
Der Inhalt der Datei robots.txt in der Root.
Es gibt jeweils eine Sektion für zusätzliche HTTP sowie HTTPS Header Felder. Einträge in den jeweiligen Tabellen werden als Header Felder der HTTP/HTTPS Antwort vom Server an den Browser gesendet. Es können beliebige Felder gesetzt werden, z.B. Felder die für das HSTS Verfahren benötigt werden. Es wird empfohlen, eigene Header Felder mit dem Präfix X-
zu versehen, um sie von den Standardfeldern unterscheiden zu können.
Hinweis: Header, die für die Einrichtung von HSTS interessant sein können, sind in der Reverse-Proxy-Konfiguration dokumentiert. Wenn Sie keinen Reverse-Proxy verwenden, können Sie diese Header auch hier setzen.
Hinweis: Die Verwendung dieses Features muss sorgfältig abgewogen werden, da Fehler dazu führen können, dass der Zugriff mittels Browser auf die Oberfläche nicht mehr funktioniert.