Authentifizierung
Restorm hat kein Dropdown-Menü „Authentifizierungstyp“. Es gibt stattdessen etwas Allgemeineres: die Authentifizierungsanfrage, eine vollwertige Anfrage, deren Aufgabe es ist, Header für andere Anfragen zu erzeugen.
Der Vorteil: So lässt sich jedes Schema abbilden, auch solche, die keine Dropdown-Liste vorsieht — ein zweistufiger Austausch, ein signiertes Token, eine hausinterne API. Der Nachteil: Man muss es einmal schreiben.
Eine Authentifizierungsroute erstellen
Section titled “Eine Authentifizierungsroute erstellen”Rechtsklick auf einen Variablenordner ▸ Hinzufügen ▸ Authentifizierungsanfrage.
Konfigurieren Sie den Aufruf zunächst wie jede andere HTTP-Anfrage: Methode, URL, Header, Body. Öffnen Sie dann den Tab Konfiguration, der die drei authentifizierungsspezifischen Einstellungen enthält.
Erzeugte Header
Section titled “Erzeugte Header”Die Liste der Header, die diese Route in jede Anfrage einfügt, die sie referenziert. Jeder Wert ist ein Ausdruck, der auf dem Antwort-Body der Authentifizierungsanfrage ausgewertet wird.
| Header | Wert |
|---|---|
Authorization | {{token_type}} {{access_token}} |
Ablauf (Sekunden)
Section titled “Ablauf (Sekunden)”Ein ebenfalls auf dem Antwort-Body ausgewerteter Ausdruck, der die
Gültigkeitsdauer in Sekunden liefert — typischerweise {{expires_in}}. Bleibt
das Feld leer, läuft das Token nie von selbst ab.
Authentifizierungsfehlercodes
Section titled “Authentifizierungsfehlercodes”Die HTTP-Statuscodes, die bei einer Anfrage mit dieser Route eine
Token-Erneuerung mit anschließendem automatischem Wiederholungsversuch
auslösen. Standardmäßig: 401 und 403.
Zwei Begriffe, eine Sache
Section titled “Zwei Begriffe, eine Sache”Eine Authentifizierungsanfrage ist das Element, das Sie im Baum anlegen. Eine Authentifizierungsroute ist dasselbe Element, betrachtet von einer anderen Anfrage aus, im Selektor, der sie anbindet. Beide Begriffe bezeichnen dieselbe Entität an zwei Stellen der Oberfläche.
Eine Route an eine Anfrage anbinden
Section titled “Eine Route an eine Anfrage anbinden”Im Tab der Anfrage, in der Smartbar, listet ein Selektor Authentifizierungsroute die Routen des Variablenordners auf. Die Standardbeschriftung lautet Keine Authentifizierung.
Sobald sie angebunden ist, werden die erzeugten Header bei jedem Senden
eingefügt, das Token wird bis zu seinem Ablauf zwischengespeichert, und ein
401 löst eine transparente Erneuerung aus.
Gängige Rezepte
Section titled “Gängige Rezepte”Bearer / OAuth-2-Client-Credentials
Section titled “Bearer / OAuth-2-Client-Credentials”Anfrage: POST https://auth.exemple.test/oauth/token, Body
x-www-form-urlencoded mit grant_type=client_credentials,
client_id={{clientId}}, client_secret={{clientSecret}}
(das Secret ist dabei ein Wert vom Typ Secret).
Erzeugter Header: Authorization = {{token_type}} {{access_token}}.
Ablauf: {{expires_in}}.
Keine Anfrage ist nötig, wenn Sie die Zugangsdaten bereits haben: Setzen Sie einfach den Header auf die Anfrage (oder auf den Ordner):
Authorization = Basic {{base64Encode (append (append user ":") password)}}
API-Schlüssel
Section titled “API-Schlüssel”Ein Header oder ein Anfrageparameter genügt:
X-API-Key = {{apiKey}}, wobei der Schlüssel eine Variable vom Typ Secret
ist.
In zwei Aufrufen erhaltenes Token
Section titled “In zwei Aufrufen erhaltenes Token”Erstellen Sie ein Szenario: erster
Aufruf, Extraktion des Zwischencodes, zweiter Aufruf, dann Variable setzen,
um das Token in den Run-Variablen abzulegen. Die nachfolgenden Anfragen des
Szenarios lesen es mit {{jeton}}.
Was der Import macht
Section titled “Was der Import macht”Beim Import einer Spezifikation werden die deklarierten Sicherheitsschemata in vorverdrahtete Header oder Parameter übersetzt, mit einer für Sie angelegten Umgebungsvariable:
| Schema in der Spezifikation | Was Restorm setzt |
|---|---|
apiKey (Header oder Anfrage) | Ein nach dem Schema benanntes Paar, Wert {{<schema>}} |
http / basic | Authorization: Basic {{<schema>_credentials}} |
http / bearer, oauth2, openIdConnect | Authorization: Bearer {{<schema>_token}} |
Sie müssen nur noch die Variable befüllen oder sie durch eine Authentifizierungsroute ersetzen, wenn Sie die automatische Erneuerung wollen.
Protokollspezifische native Zugangsdaten
Section titled “Protokollspezifische native Zugangsdaten”Manche Protokolle laufen nicht über HTTP-Header. Ihre Zugangsdaten sind Felder der Anfrage selbst:
| Protokoll | Felder |
|---|---|
| MQTT | username, password, Client-Kennung |
| AMQP | username, password, vhost |
| Redis | password |
| Kafka | SASL-Mechanismus (plain, scram-sha-256, scram-sha-512), Kennung, Passwort, TLS |
| STOMP | Header login und passcode des CONNECT |
| gRPC | Metadaten des Aufrufs |
Jedes dieser Passwörter akzeptiert einen Wert vom Typ Secret.