Aktuelle Version vom 19. Mai 2026, 07:11 Uhr

Ein Zugang (Account) ist der Kanal, über den ein externer Konsument den REST-Server anspricht. Er bündelt API-Key, Host-Beschränkung, CORS-Konfiguration, optionale JWT-Authentifizierung und optionale mTLS-Subject-Prüfung.

Aufruf

Stammdaten -> Z Weitere Stammdaten -> REST-Server -> Zugänge

Felder

Feld	Beschreibung
Name	Sprechender Name, erscheint im Protokoll und der Statistik
Aktiv	Inaktive Zugänge werden bei der Authentifizierung mit 403 abgewiesen
API-Key	Eindeutiger Schlüssel, den der Konsument im HTTP-Header apikey senden muss. Per Schlüsselsymbol generierbar
Host	Optionaler Hostname oder IP-Adresse des Konsumenten. Stimmt die anfragende IP nicht überein, wird mit 403 abgelehnt
CORS-Origins	Liste erlaubter Origins für Browser-Aufrufe, mehrere durch ; getrennt
mTLS-Subject	Erwarteter Substring im Client-Zertifikat-Subject (nur sinnvoll bei mTLS-Servern)
JWT	Schalter, ob für diesen Zugang ein JWT-Token nötig ist
JWT-Endpunkt	Adresse, über die der JWT-Token bezogen wird (z.B. oauth), darf keinen / enthalten
JWT-Key	Geheimer Schlüssel zur Signierung/Verifikation, per Schlüsselsymbol generierbar
JWT-Exp	Gültigkeitsdauer eines ausgestellten Tokens in Minuten

API-Key

Der API-Key ist die Basis-Authentifizierung. Der Client übergibt ihn im HTTP-Header:

apikey: abcd-efgh-ijkl-mnop-qrstuvwxyz12

Wird ein Aufruf ohne apikey-Header gestellt, sucht der Server intern nach einem Zugang mit API-Key * - damit lassen sich (mit Vorsicht!) auch öffentliche Endpunkte ohne Authentifizierung realisieren.

HINWEIS: Ein Zugang mit API-Key * sollte nur für bewusst freigegebene Endpunkte verwendet werden und immer in Kombination mit einer Host-Beschränkung oder CORS-Beschränkung betrieben werden.

Host-Beschränkung

Ist im Feld Host ein Wert hinterlegt, akzeptiert der Server Anfragen unter diesem Zugang nur dann, wenn die Remote-IP exakt diesem Host entspricht oder durch DNS-Auflösung auf diese IP zeigt. DNS-Auflösungen werden 5 Minuten gecached.

CORS

Soll ein Endpunkt aus einer Browser-Anwendung (Single-Page-App, JavaScript) heraus aufgerufen werden, muss das Origin der Anwendung in der CORS-Liste des Zugangs eingetragen sein.

Format der Liste:

https://app.kunde.de;https://test.kunde.de;https://localhost:8080

Ablauf:

Browser sendet einen Preflight-Request (OPTIONS). Der REST-Server prüft das Origin gegen die globale Origin-Liste aller Accounts (Cache, TTL 60s) und antwortet mit 204 + CORS-Header, falls erlaubt.
Der eigentliche Request wird gegen die Origin-Liste des aktuell verwendeten Zugangs geprüft.
Stimmt das Origin nicht, wird mit 403 Origin nicht erlaubt für Account ... abgelehnt.

Erlaubte Methoden: GET, POST, PUT, DELETE, PATCH. Erlaubte Header: Content-Type, apikey, Authorization, Accept. Diese Werte sind systemseitig festgelegt und werden in der Preflight-Antwort zurückgegeben.

JWT-Authentifizierung

Wird ein Zugang mit aktiver JWT-Pflicht aufgerufen, sind zwei Phasen zu durchlaufen:

Phase 1: Token-Bezug

Der Konsument ruft den JWT-Endpunkt des Zugangs auf, z.B.:

POST https://api.meinserver.de/oauth/
Header: apikey: [API-KEY]
Body:   {"username":"...", "password":"..."}

Der Server führt das im Zugang hinterlegte Authentifizierungs-Skript aus (F7 in der Zugangs-Liste). Das Skript muss eine Funktion Authenticate bereitstellen, die ein JSON-Objekt mit:

status = 1 bei Erfolg, 9 bei Misserfolg
error = Fehlertext (bei status=9)
_OBS_JWT_ID, _OBS_JWT_SUBJECT, _OBS_JWT_AUDIENCE für die JWT-Claims (optional)

zurückliefert. Bei Erfolg signiert der Server einen Token (HS256, Issuer OBS REST-Server, Lebenszeit gemäß JWT-Exp) und antwortet:

{"token": "eyJhbGciOi..."}

Phase 2: Token-Verwendung

Bei allen folgenden Aufrufen sendet der Client den Token im Authorization-Header:

GET https://api.meinserver.de/kalender/v1
Header: apikey: [API-KEY]
        Authorization: Bearer eyJhbGciOi...

Der Server verifiziert Signatur, Issuer, Ausstellzeitpunkt und Ablauf (Toleranz: 20 Sekunden Clock-Skew). Im Skript stehen die Claims als Parameter _OBS_JWT_ID, _OBS_JWT_SUBJECT und _OBS_JWT_AUDIENCE zur Verfügung.

Details und ein vollständiges Beispiel siehe Scripting.

mTLS-Subject-Prüfung

Wird im Feld mTLS-Subject ein Wert hinterlegt, prüft der Server zusätzlich zur Standard-mTLS-Validierung, ob der Subject-DN des Client-Zertifikats den hinterlegten Text enthält (case-insensitiv, Substring-Match).

Beispiele für Subject-Strings im Cert:

/C=DE/O=Kunde GmbH/CN=client-prod.kunde.de
/C=DE/O=Kunde GmbH/CN=client-test.kunde.de

Mit CN=client-prod im Feld wird genau das prod-Cert akzeptiert, das test-Cert wird mit 401 abgewiesen. Damit lassen sich verschiedene Konsumenten über dieselbe CA klar voneinander trennen.

Listen-Funktionen

In der Zugänge-Liste (allein):

Einfg - neuer Zugang
Return - Zugang bearbeiten
F4 - Sortierung
F7 - JWT-Authentifizierungs-Skript bearbeiten
F8 - Statistik für den Zugang

Aus der Endpunkt-Liste via F6 geöffnet (Auswahl für Berechtigung):

F2 - markierte Zugänge dem Endpunkt zuordnen
F5 - Zugang in der Liste markieren / Markierung aufheben

@@ Zeile 1: / Zeile 1: @@
-<br>Sеarch for online reputatiоn management services delhi? I do this ϳob. Ꭺѕ it totallly an underground job It's impossible to use my own site So please place yoᥙr order through email: yangzɦߋu2130@gmaiⅼ.com or  turn off goⲟgle image search scrubbіng yanshaiodong@qq.cօm, skype:yarkwinter, phone:+ 86 189-8383-9805. Guaranteed negative reinforcement vs punishment by removaⅼ definition  website google ranking factors seo or ѕеnd back your money.<br><br>It has never been еasy tօ deindex a negative review. It's why number of dеfamаtion vісtims have been scamed by reputation company. Actually thiѕ is an unusual wich needs expert working in this sector. My ten years of experiences are your trust for the removal.<br>online reputation management services nationwide retirement ѕolution<br>
+{{Kostenpflichtige Module}}
+=Zugänge=
+Ein '''Zugang''' (Account) ist der Kanal, über den ein externer Konsument den REST-Server anspricht. Er bündelt API-Key, Host-Beschränkung, CORS-Konfiguration, optionale JWT-Authentifizierung und optionale mTLS-Subject-Prüfung.
+==Aufruf==
+'''Stammdaten -> Z Weitere Stammdaten -> REST-Server -> Zugänge'''
+==Felder==
+{| class="wikitable"
+! Feld          !! Beschreibung
+|-
+| Name          || Sprechender Name, erscheint im Protokoll und der Statistik
+|-
+| Aktiv         || Inaktive Zugänge werden bei der Authentifizierung mit 403 abgewiesen
+|-
+| API-Key       || Eindeutiger Schlüssel, den der Konsument im HTTP-Header ''apikey'' senden muss. Per Schlüsselsymbol generierbar
+|-
+| Host          || Optionaler Hostname oder IP-Adresse des Konsumenten. Stimmt die anfragende IP nicht überein, wird mit 403 abgelehnt
+|-
+| CORS-Origins  || Liste erlaubter Origins für Browser-Aufrufe, mehrere durch '';'' getrennt
+|-
+| mTLS-Subject  || Erwarteter Substring im Client-Zertifikat-Subject (nur sinnvoll bei mTLS-Servern)
+|-
+| JWT           || Schalter, ob für diesen Zugang ein JWT-Token nötig ist
+|-
+| JWT-Endpunkt  || Adresse, über die der JWT-Token bezogen wird (z.B. ''oauth''), darf keinen ''/'' enthalten
+|-
+| JWT-Key       || Geheimer Schlüssel zur Signierung/Verifikation, per Schlüsselsymbol generierbar
+|-
+| JWT-Exp       || Gültigkeitsdauer eines ausgestellten Tokens in Minuten
+|}
+==API-Key==
+Der API-Key ist die Basis-Authentifizierung. Der Client übergibt ihn im HTTP-Header:
+ apikey: abcd-efgh-ijkl-mnop-qrstuvwxyz12
+Wird ein Aufruf ohne ''apikey''-Header gestellt, sucht der Server intern nach einem Zugang mit API-Key '''*''' - damit lassen sich (mit Vorsicht!) auch öffentliche Endpunkte ohne Authentifizierung realisieren.
+{{Hinweis|Ein Zugang mit API-Key ''*'' sollte nur für bewusst freigegebene Endpunkte verwendet werden und immer in Kombination mit einer Host-Beschränkung oder CORS-Beschränkung betrieben werden.}}
+==Host-Beschränkung==
+Ist im Feld '''Host''' ein Wert hinterlegt, akzeptiert der Server Anfragen unter diesem Zugang nur dann, wenn die Remote-IP exakt diesem Host entspricht oder durch DNS-Auflösung auf diese IP zeigt. DNS-Auflösungen werden 5 Minuten gecached.
+==CORS==
+Soll ein Endpunkt aus einer Browser-Anwendung (Single-Page-App, JavaScript) heraus aufgerufen werden, muss das Origin der Anwendung in der CORS-Liste des Zugangs eingetragen sein.
+Format der Liste:
+  https://app.kunde.de;https://test.kunde.de;https://localhost:8080
+Ablauf:
+# Browser sendet einen Preflight-Request (''OPTIONS''). Der REST-Server prüft das Origin gegen die globale Origin-Liste aller Accounts (Cache, TTL 60s) und antwortet mit 204 + CORS-Header, falls erlaubt.
+# Der eigentliche Request wird gegen die Origin-Liste des aktuell verwendeten Zugangs geprüft.
+# Stimmt das Origin nicht, wird mit 403 ''Origin nicht erlaubt für Account ...'' abgelehnt.
+Erlaubte Methoden: ''GET, POST, PUT, DELETE, PATCH''. Erlaubte Header: ''Content-Type, apikey, Authorization, Accept''. Diese Werte sind systemseitig festgelegt und werden in der Preflight-Antwort zurückgegeben.
+==JWT-Authentifizierung==
+Wird ein Zugang mit aktiver JWT-Pflicht aufgerufen, sind zwei Phasen zu durchlaufen:
+===Phase 1: Token-Bezug===
+Der Konsument ruft den JWT-Endpunkt des Zugangs auf, z.B.:
+ POST https://api.meinserver.de/oauth/
+ Header: apikey: [API-KEY]
+ Body:   {"username":"...", "password":"..."}
+Der Server führt das im Zugang hinterlegte '''Authentifizierungs-Skript''' aus (F7 in der Zugangs-Liste). Das Skript muss eine Funktion ''Authenticate'' bereitstellen, die ein JSON-Objekt mit:
+* ''status'' = ''1'' bei Erfolg, ''9'' bei Misserfolg
+* ''error'' = Fehlertext (bei status=9)
+* ''_OBS_JWT_ID'', ''_OBS_JWT_SUBJECT'', ''_OBS_JWT_AUDIENCE'' für die JWT-Claims (optional)
+zurückliefert. Bei Erfolg signiert der Server einen Token (HS256, Issuer ''OBS REST-Server'', Lebenszeit gemäß JWT-Exp) und antwortet:
+ {"token": "eyJhbGciOi..."}
+===Phase 2: Token-Verwendung===
+Bei allen folgenden Aufrufen sendet der Client den Token im ''Authorization''-Header:
+ GET https://api.meinserver.de/kalender/v1
+  Header: apikey: [API-KEY]
+         Authorization: Bearer eyJhbGciOi...
+Der Server verifiziert Signatur, Issuer, Ausstellzeitpunkt und Ablauf (Toleranz: 20 Sekunden Clock-Skew). Im Skript stehen die Claims als Parameter ''_OBS_JWT_ID'', ''_OBS_JWT_SUBJECT'' und ''_OBS_JWT_AUDIENCE'' zur Verfügung.
+Details und ein vollständiges Beispiel siehe [[OBS/Kostenpflichtige Module/RESTServer/Scripting|Scripting]].
+==mTLS-Subject-Prüfung==
+Wird im Feld '''mTLS-Subject''' ein Wert hinterlegt, prüft der Server zusätzlich zur Standard-mTLS-Validierung, ob der Subject-DN des Client-Zertifikats den hinterlegten Text enthält (case-insensitiv, Substring-Match).
+Beispiele für Subject-Strings im Cert:
+ /C=DE/O=Kunde GmbH/CN=client-prod.kunde.de
+ /C=DE/O=Kunde GmbH/CN=client-test.kunde.de
+Mit '''CN=client-prod''' im Feld wird genau das prod-Cert akzeptiert, das test-Cert wird mit 401 abgewiesen. Damit lassen sich verschiedene Konsumenten über dieselbe CA klar voneinander trennen.
+==Listen-Funktionen==
+In der Zugänge-Liste (allein):
+* '''Einfg''' - neuer Zugang
+* '''Return''' - Zugang bearbeiten
+* '''F4''' - Sortierung
+* '''F7''' - JWT-Authentifizierungs-Skript bearbeiten
+* '''F8''' - Statistik für den Zugang
+Aus der Endpunkt-Liste via F6 geöffnet (Auswahl für Berechtigung):
+* '''F2''' - markierte Zugänge dem Endpunkt zuordnen
+* '''F5''' - Zugang in der Liste markieren / Markierung aufheben

OBS/Kostenpflichtige Module/RESTServer/Zugaenge: Unterschied zwischen den Versionen

Aktuelle Version vom 19. Mai 2026, 07:11 Uhr

Inhaltsverzeichnis

Zugänge

Aufruf

Felder

API-Key

Host-Beschränkung

CORS

JWT-Authentifizierung

Phase 1: Token-Bezug

Phase 2: Token-Verwendung

mTLS-Subject-Prüfung

Listen-Funktionen

Navigationsmenü

OBS/Kostenpflichtige Module/RESTServer/Zugaenge: Unterschied zwischen den Versionen

Aktuelle Version vom 19. Mai 2026, 07:11 Uhr

Zugänge

Aufruf

Felder

API-Key

Host-Beschränkung

CORS

JWT-Authentifizierung

Phase 1: Token-Bezug

Phase 2: Token-Verwendung

mTLS-Subject-Prüfung

Listen-Funktionen

Navigationsmenü

Suche