Autentisering
Restorm har ingen rullgardinsmeny för ”autentiseringstyp”. Det har något mer generellt: autentiseringsbegäran, en fullvärdig begäran vars uppgift är att producera headers till de andra.
Fördelen: vilket schema som helst går att modellera, även de som ingen rullgardinsmeny förutser — ett utbyte i två steg, en signerad token, ett egenbyggt API. Nackdelen: du måste skriva det en gång.
Skapa en autentiseringsväg
Section titled “Skapa en autentiseringsväg”Högerklicka på en variabelmapp ▸ Lägg till ▸ Autentiseringsbegäran.
Konfigurera först anropet som vilken HTTP-begäran som helst: metod, URL, headers, kropp. Öppna sedan dess flik Konfiguration, som bär de tre inställningar som hör till autentiseringen.
Producerade headers
Section titled “Producerade headers”Listan över de headers som den här vägen injicerar i varje begäran som refererar till den. Varje värde är ett uttryck som utvärderas mot svarskroppen från autentiseringsbegäran.
| Header | Värde |
|---|---|
Authorization | {{token_type}} {{access_token}} |
Utgångstid (sekunder)
Section titled “Utgångstid (sekunder)”Ett uttryck, som också utvärderas mot svarskroppen och som ger giltighetstiden i
sekunder — typiskt {{expires_in}}. Lämnas det tomt går token aldrig ut av sig
självt.
Autentiseringens felkoder
Section titled “Autentiseringens felkoder”De HTTP-statusar som, när de tas emot av en begäran som använder den här vägen,
utlöser en förnyelse av token och sedan ett automatiskt nytt försök. Som
standard: 401 och 403.
Två termer, en och samma sak
Section titled “Två termer, en och samma sak”En autentiseringsbegäran är det objekt du skapar i trädet. En autentiseringsväg är samma objekt sett från en annan begäran, i väljaren som knyter det dit. De två termerna betecknar samma entitet, på två platser i gränssnittet.
Knyta en väg till en begäran
Section titled “Knyta en väg till en begäran”I begärans flik, i smartbaren, listar en väljare Autentiseringsväg vägarna i variabelmappen. Standardetiketten är Ingen autentisering.
När vägen är knuten injiceras de producerade headerna vid varje sändning, token
cachas fram till sin utgångstid, och en 401 utlöser en förnyelse som du inte
behöver bry dig om.
Vanliga recept
Section titled “Vanliga recept”Bearer / OAuth 2 client credentials
Section titled “Bearer / OAuth 2 client credentials”Begäran: POST https://auth.exemple.test/oauth/token, kropp
x-www-form-urlencoded med grant_type=client_credentials,
client_id={{clientId}}, client_secret={{clientSecret}}
(där hemligheten är ett värde av typen Hemlighet).
Producerad header: Authorization = {{token_type}} {{access_token}}.
Utgångstid: {{expires_in}}.
Ingen begäran behövs om du redan har inloggningsuppgifterna: lägg helt enkelt headern på begäran (eller på mappen):
Authorization = Basic {{base64Encode (append (append user ":") password)}}
API-nyckel
Section titled “API-nyckel”En header eller en frågeparameter räcker:
X-API-Key = {{apiKey}}, där nyckeln är en variabel av typen Hemlighet.
Token som hämtas i två anrop
Section titled “Token som hämtas i två anrop”Skapa ett scenario: första anropet,
extrahering av den mellanliggande koden, andra anropet, sedan Ange variabel för
att lägga token bland körningsvariablerna. Scenariots följande begäranden läser
den med {{jeton}}.
Vad importen gör
Section titled “Vad importen gör”När en specifikation importeras översätts de deklarerade säkerhetsschemorna till färdigkopplade headers eller parametrar, med en miljövariabel som skapas åt dig:
| Schema i specifikationen | Vad Restorm lägger in |
|---|---|
apiKey (header eller fråga) | Ett par som namnges efter schemat, värde {{<schema>}} |
http / basic | Authorization: Basic {{<schema>_credentials}} |
http / bearer, oauth2, openIdConnect | Authorization: Bearer {{<schema>_token}} |
Allt som återstår är att fylla i variabeln, eller att byta ut den mot en autentiseringsväg om du vill ha automatisk förnyelse.
Nativa inloggningsuppgifter per protokoll
Section titled “Nativa inloggningsuppgifter per protokoll”Vissa protokoll går inte via HTTP-headers. Deras inloggningsuppgifter är fält i begäran själv:
| Protokoll | Fält |
|---|---|
| MQTT | username, password, klient-id |
| AMQP | username, password, vhost |
| Redis | password |
| Kafka | SASL-mekanism (plain, scram-sha-256, scram-sha-512), användarnamn, lösenord, TLS |
| STOMP | Headerna login och passcode i CONNECT |
| gRPC | Anropets metadata |
Vart och ett av dessa lösenord accepterar ett värde av typen Hemlighet.