OBS/Kostenpflichtige Module/RESTServer/Server-Profile: Unterschied zwischen den Versionen
Böhrer (Diskussion | Beiträge) (Die Seite wurde neu angelegt: „Hі there, I am Louis Fiorini. He ϲurrently lives іn Hawaii and Һe loves just аbout living generaⅼly. Heг ԁay job іs a messenger. Ⲟne of tһe vеry…“) |
(Die Seite wurde neu angelegt: „{{Kostenpflichtige Module}} =Server-Profile= Ein '''Server''' im REST-Modul ist ein eigenstaendiges TLS-Profil mit einer eigenen HTTP-Server-Instanz. In OBS koennen beliebig viele Server-Profile parallel betrieben werden, jedes mit eigenem Modus, eigenen Zertifikaten und eigenen Bindungen. Typische Einsatzfaelle fuer mehrere Profile: * Ein '''Public-Profil''' mit Standard-TLS auf Port 443 fuer externe Konsumenten. * Ein '''Internal-mTLS-Profil''' auf…“) |
||
| Zeile 1: | Zeile 1: | ||
{{Kostenpflichtige Module}} | |||
=Server-Profile= | |||
Ein '''Server''' im REST-Modul ist ein eigenstaendiges TLS-Profil mit einer eigenen HTTP-Server-Instanz. In OBS koennen beliebig viele Server-Profile parallel betrieben werden, jedes mit eigenem Modus, eigenen Zertifikaten und eigenen Bindungen. | |||
Typische Einsatzfaelle fuer mehrere Profile: | |||
* Ein '''Public-Profil''' mit Standard-TLS auf Port 443 fuer externe Konsumenten. | |||
* Ein '''Internal-mTLS-Profil''' auf einem internen Port fuer Microservices, die zwingend ein Client-Zertifikat vorlegen muessen. | |||
* Ein '''Debug-Profil''' mit Plain-HTTP auf 127.0.0.1, ausschliesslich fuer lokale Tests. | |||
==Aufruf== | |||
'''Stammdaten -> Z Weitere Stammdaten -> REST-Server -> Server''' | |||
==Felder des Server-Profils== | |||
{| class="wikitable" | |||
! Feld !! Beschreibung | |||
|- | |||
| Nr || Eindeutige Nummer 1-99, einmalig vergeben, kann spaeter nicht mehr geaendert werden | |||
|- | |||
| Name || Sprechender Name, eindeutig - erscheint in Protokoll, Statistik und Endpunkt-Zuordnung | |||
|- | |||
| Aktiv || Profil wird beim Start des REST-Dienstes geladen. Inaktive Profile starten nicht | |||
|- | |||
| Info || Freitext zur Dokumentation (interner Kommentar, wird nicht ausgewertet) | |||
|- | |||
| Kein SSL || Plain-HTTP-Modus, ausschliesslich fuer Debug. TLS-Felder werden ignoriert | |||
|- | |||
| mTLS || Mutual TLS: jeder Client muss ein gueltiges Client-Zertifikat vorlegen | |||
|- | |||
| Cert || PEM-Inhalt des Server-Zertifikats (inkl. ggf. Zwischen-CA-Kette) | |||
|- | |||
| Key || PEM-Inhalt des privaten Schluessels | |||
|- | |||
| Root-Cert || PEM-Inhalt des CA-Root-Zertifikats (Pflicht bei Standard-TLS, dort fuer Chain-Validierung, sowie bei mTLS, dort zusaetzlich fuer Client-Cert-Verifikation) | |||
|} | |||
Die Inhalte der Zertifikate werden direkt in OBS als Text gespeichert. Zur Laufzeit schreibt der Server die PEM-Inhalte fuer den Bruchteil einer Sekunde in ein Temp-Verzeichnis, damit OpenSSL sie beim Start lesen kann; danach werden die Temp-Dateien sofort wieder geloescht. | |||
==Modi== | |||
{| class="wikitable" | |||
! Modus !! Voraussetzungen !! Anwendung | |||
|- | |||
| '''Standard-TLS''' || Cert + Key + Root-Cert hinterlegt || Empfohlener Default fuer alle Server, die ueber das oeffentliche Netz erreichbar sind | |||
|- | |||
| '''mTLS''' || Cert + Key + Root-Cert (CA) || Maschine-zu-Maschine-Kommunikation, in der jeder Client mit Cert validiert wird | |||
|- | |||
| '''Plain-HTTP''' || Haken ''Kein SSL'' || Ausschliesslich lokale Tests. Erkennt TLS-Versuche auf dem Plain-Port und trennt sie direkt | |||
|} | |||
{{Hinweis|Bei Standard-TLS und mTLS faehrt der Server ohne Cert/Key gar nicht erst hoch. Bei Standard-TLS ohne Root-Cert wird die Anlage abgelehnt - die Chain-Validierung benoetigt das CA-Root. Plain-HTTP umgeht TLS komplett und ist nicht fuer Produktivumgebungen geeignet.}} | |||
==Validierung beim Speichern== | |||
Beim Speichern wird geprueft: | |||
* Nr und Name muessen vergeben sein. | |||
* Nr muss eindeutig sein. | |||
* Name muss eindeutig sein. | |||
* Bei nicht aktiviertem ''Kein SSL'' muessen Cert und Key vorhanden sein. | |||
* Bei nicht aktiviertem ''mTLS'' (= Standard-TLS) muss Root-Cert vorhanden sein. | |||
==Bindungen== | |||
Eine Bindung ist die Kombination aus IP-Adresse und Port, auf der ein Server-Profil lauscht. Pro Server-Profil koennen mehrere Bindungen existieren, z.B. um die gleiche TLS-Konfiguration parallel auf 443 und 8443 anzubieten. | |||
===Aufruf=== | |||
In der Server-Liste den gewuenschten Server markieren und '''F6''' druecken. Es oeffnet sich die zum Server gehoerende Bindungs-Liste. | |||
===Felder=== | |||
{| class="wikitable" | |||
! Feld !! Beschreibung | |||
|- | |||
| Host || IP-Adresse oder Hostname, auf dem gelauscht wird. ''0.0.0.0'' = alle IPv4-Adressen; ''127.0.0.1'' = nur lokal; explizite IPs binden gezielt auf eine Netzwerkkarte | |||
|- | |||
| Port || TCP-Port (1-65535). 443/8443 fuer HTTPS, frei waehlbar fuer Debug-Profile | |||
|- | |||
| Aktiv || Bindung wird beim Server-Start geladen | |||
|- | |||
| Standard|| Markiert die Standard-Bindung des Servers. Pro Server-Profil ist nur eine Standard-Bindung erlaubt | |||
|} | |||
===Wirksamkeit=== | |||
Bindungen werden ausschliesslich beim Start des REST-Dienstes geladen. Aenderungen werden daher erst nach einem Neustart aktiv. Bis dahin laufen die alten Bindungen weiter. | |||
==Listen-Funktionen== | |||
In der Server-Liste: | |||
* '''Einfg''' - neues Server-Profil | |||
* '''Return''' - vorhandenes Profil bearbeiten | |||
* '''F4''' - Sortierung waehlen | |||
* '''F6''' - Bindungs-Liste des markierten Servers | |||
Version vom 19. Mai 2026, 06:42 Uhr
- A Preise aktualisieren
- C Personen übertragen
- E Kategorien verwalten
- G Kataloge verwalten
- I Merkliste übertragen
- K Varianten übertragen
- L Artikelvarianten übertragen
- M Referenzarten übertragen
- N Lagerbestände verwalten
- U Bestellungen einlesen
- V leere Passworte füllen
- W Update-Informationen zurücksetzen
- X Konfiguration
- Z Protokoll
Server-Profile
Ein Server im REST-Modul ist ein eigenstaendiges TLS-Profil mit einer eigenen HTTP-Server-Instanz. In OBS koennen beliebig viele Server-Profile parallel betrieben werden, jedes mit eigenem Modus, eigenen Zertifikaten und eigenen Bindungen.
Typische Einsatzfaelle fuer mehrere Profile:
- Ein Public-Profil mit Standard-TLS auf Port 443 fuer externe Konsumenten.
- Ein Internal-mTLS-Profil auf einem internen Port fuer Microservices, die zwingend ein Client-Zertifikat vorlegen muessen.
- Ein Debug-Profil mit Plain-HTTP auf 127.0.0.1, ausschliesslich fuer lokale Tests.
Aufruf
Stammdaten -> Z Weitere Stammdaten -> REST-Server -> Server
Felder des Server-Profils
| Feld | Beschreibung |
|---|---|
| Nr | Eindeutige Nummer 1-99, einmalig vergeben, kann spaeter nicht mehr geaendert werden |
| Name | Sprechender Name, eindeutig - erscheint in Protokoll, Statistik und Endpunkt-Zuordnung |
| Aktiv | Profil wird beim Start des REST-Dienstes geladen. Inaktive Profile starten nicht |
| Info | Freitext zur Dokumentation (interner Kommentar, wird nicht ausgewertet) |
| Kein SSL | Plain-HTTP-Modus, ausschliesslich fuer Debug. TLS-Felder werden ignoriert |
| mTLS | Mutual TLS: jeder Client muss ein gueltiges Client-Zertifikat vorlegen |
| Cert | PEM-Inhalt des Server-Zertifikats (inkl. ggf. Zwischen-CA-Kette) |
| Key | PEM-Inhalt des privaten Schluessels |
| Root-Cert | PEM-Inhalt des CA-Root-Zertifikats (Pflicht bei Standard-TLS, dort fuer Chain-Validierung, sowie bei mTLS, dort zusaetzlich fuer Client-Cert-Verifikation) |
Die Inhalte der Zertifikate werden direkt in OBS als Text gespeichert. Zur Laufzeit schreibt der Server die PEM-Inhalte fuer den Bruchteil einer Sekunde in ein Temp-Verzeichnis, damit OpenSSL sie beim Start lesen kann; danach werden die Temp-Dateien sofort wieder geloescht.
Modi
| Modus | Voraussetzungen | Anwendung |
|---|---|---|
| Standard-TLS | Cert + Key + Root-Cert hinterlegt | Empfohlener Default fuer alle Server, die ueber das oeffentliche Netz erreichbar sind |
| mTLS | Cert + Key + Root-Cert (CA) | Maschine-zu-Maschine-Kommunikation, in der jeder Client mit Cert validiert wird |
| Plain-HTTP | Haken Kein SSL | Ausschliesslich lokale Tests. Erkennt TLS-Versuche auf dem Plain-Port und trennt sie direkt |
Validierung beim Speichern
Beim Speichern wird geprueft:
- Nr und Name muessen vergeben sein.
- Nr muss eindeutig sein.
- Name muss eindeutig sein.
- Bei nicht aktiviertem Kein SSL muessen Cert und Key vorhanden sein.
- Bei nicht aktiviertem mTLS (= Standard-TLS) muss Root-Cert vorhanden sein.
Bindungen
Eine Bindung ist die Kombination aus IP-Adresse und Port, auf der ein Server-Profil lauscht. Pro Server-Profil koennen mehrere Bindungen existieren, z.B. um die gleiche TLS-Konfiguration parallel auf 443 und 8443 anzubieten.
Aufruf
In der Server-Liste den gewuenschten Server markieren und F6 druecken. Es oeffnet sich die zum Server gehoerende Bindungs-Liste.
Felder
| Feld | Beschreibung |
|---|---|
| Host | IP-Adresse oder Hostname, auf dem gelauscht wird. 0.0.0.0 = alle IPv4-Adressen; 127.0.0.1 = nur lokal; explizite IPs binden gezielt auf eine Netzwerkkarte |
| Port | TCP-Port (1-65535). 443/8443 fuer HTTPS, frei waehlbar fuer Debug-Profile |
| Aktiv | Bindung wird beim Server-Start geladen |
| Standard | Markiert die Standard-Bindung des Servers. Pro Server-Profil ist nur eine Standard-Bindung erlaubt |
Wirksamkeit
Bindungen werden ausschliesslich beim Start des REST-Dienstes geladen. Aenderungen werden daher erst nach einem Neustart aktiv. Bis dahin laufen die alten Bindungen weiter.
Listen-Funktionen
In der Server-Liste:
- Einfg - neues Server-Profil
- Return - vorhandenes Profil bearbeiten
- F4 - Sortierung waehlen
- F6 - Bindungs-Liste des markierten Servers