Web Server

Ermöglicht grundlegende Verbindungseinstellungen für den internen Webserver, wie HTTP und HTTPS Verbindungen.

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.

Typ

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.

  • Standardwert: HTTP

Gebundene IP-Adresse

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.

Context

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.

HTTP Port

Die Serveranwendung lauscht auf dem angegebenen Port auf neue Berichtsanfragen.

HTTPS Port

Die Serveranwendung lauscht für verschlüsselte Anfragen auf dem angegebenen Port auf neue Berichtsanfragen.

Weiterleitung aller HTTP-Anfragen auf HTTPS

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.

Zertifikat-Quelle

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.

Zertifikat

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.

Privater Schlüssel

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.

Externe sichtbare URL

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.

Performance

Einstellungen, welche die Anzahl gleichzeitiger Anfragen begrenzen, um den internen Webserver zu beschleunigen.

Max. Gleichzeitige Anfragen

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.

  • Standardwert: 500

Max. HTTP Anfragen

Dies ist die Anzahl der gleichzeitigen HTTP-Anfragen die vom Server angenommen und bearbeitet werden. Weitere Anfragen werden eingereiht.

  • Standardwert: 250

Max. Heap Memory

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.

Sprache des Servers

Die Sprache des Servers wird für die Ausgabe von Fehlermeldungen verwendet. Diese Eigenschaft entspricht dem Java VM Parameter: -Duser.language.

  • Standardwert: Systemeinstellung des Betriebssystems

Land des Servers

Das Land des Servers wird für die Währungsformatierung verwendet. Diese Eigenschaft entspricht dem Java VM Parameter: -Duser.country.

  • Standardwert: Systemeinstellung des Betriebssystems

Andere VM-Argumente

Dies wird direkt an die Java VM als Argument weitergeleitet.

  • Standardwert: leer
  • Beispiel: -javaagent:c:\path\to\your\javaagent.jar

Server neustarten

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.

Sicherheit

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.

Frame-Einbettung

Mit dieser Konfigurationseigenschaft können Frame-Einbettungen unter Verwendung des Header-Feldes X-Frame-Options eingerichtet werden. Die unterstützten Werte sind:

  • Immer erlaubt: Der Header ist nicht gesetzt
  • Verweigern: Der Header ist auf DENY gesetzt und die Frame-Einbettung der Anwendungen ist nicht erlaubt
  • Gleicher Ursprung: Der Header ist auf SAMEORIGIN gesetzt und erlaubt die Einbettung der Anwendung nur von derselben Ursprungsadresse.

Erlaubte Origins

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:

  1. die Werte aus diesem Feld und
  2. die externe sichtbare URL

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.

Beispiele

*

oder

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

oder

*.example.com

crossdomain.xml

Mit dieser Option wird der Inhalt der Datei crossdomain.xml dieses Servers angepasst. Die Datei crossdomain.xml regelt, wie andere Domänen und Quellen mit den Webinhalten des Benutzers interagieren können. Sie können in der Datei crossdomain.xml Regeln und Berechtigungen definieren, um festzulegen, welche externen Domänen auf Daten oder Ressourcen auf diesem Server zugreifen dürfen. Diese Anpassung gewährleistet kontrollierte und sichere domänenübergreifende Interaktionen, schützt sensible Informationen und verbessert die allgemeine Sicherheitslage dieses Servers.

robots.txt

Die Option robots.txt ermöglicht die Anpassung des Inhalts der entsprechenden Datei im Stammverzeichnis dieses Servers. Die Datei robots.txt weist Suchmaschinen-Bots und andere automatisierte Tools an, welche Teile der Website zu crawlen und welche zu vermeiden sind. Sie können Regeln mit Direktiven wie "User-agent", "Disallow" und "Allow" festlegen, um die Indizierung und Sichtbarkeit des Inhalts Ihrer Website in den Suchergebnissen zu steuern. Diese Anpassung hilft dabei, die Interaktion von Bots mit der Website zu steuern und den Datenschutz zu wahren.

security.txt

Mit der Konfiguration security.txt können Sie den Inhalt der Datei /.well-known/security.txt dieses Servers festlegen. Die Datei security.txt dient als standardisierte Methode für Organisationen, ihre Sicherheitskontaktinformationen und Richtlinien zur Offenlegung von Schwachstellen zu kommunizieren. Mit dieser Konfiguration können Sie angeben, wie sicherheitsbezogene Angelegenheiten gemeldet und behandelt werden sollen, einschließlich der Kontaktdaten und bevorzugten Kommunikationskanäle. Durch die Anpassung des Inhalts der Datei security.txt können Sie den Meldeprozess für Sicherheitsforscher und ethische Hacker rationalisieren und so eine sicherere Online-Umgebung fördern.

Zusätzliche HTTP Header

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.