Autentisering
Restorm har ingen nedtrekksmeny for «autentiseringstype». Den har noe mer generelt: autentiseringsforespørselen, en fullverdig forespørsel som har som oppgave å produsere headere for de andre.
Fordelen: alle skjemaer kan modelleres, også de som ingen nedtrekksliste har tenkt på — en utveksling i to trinn, et signert token, et hjemmelaget API. Ulempen: du må skrive det én gang.
Opprette en autentiseringsrute
Section titled “Opprette en autentiseringsrute”Høyreklikk på en miljømappe ▸ Legg til ▸ Autentiseringsforespørsel.
Sett først opp kallet som en helt vanlig HTTP-forespørsel: metode, URL, headere, kropp. Åpne deretter fanen Konfigurasjon, som bærer de tre innstillingene som er spesifikke for autentisering.
Genererte headere
Section titled “Genererte headere”Listen over headere som denne ruten kommer til å injisere i hver forespørsel som refererer til den. Hver verdi er et uttrykk som evalueres mot svarkroppen til autentiseringsforespørselen.
| Header | Verdi |
|---|---|
Authorization | {{token_type}} {{access_token}} |
Utløpstid (sekunder)
Section titled “Utløpstid (sekunder)”Et uttrykk, også det evaluert mot svarkroppen, som gir gyldighetstiden i sekunder
— typisk {{expires_in}}. Står feltet tomt, utløper tokenet aldri av seg selv.
Feilkoder for autentisering
Section titled “Feilkoder for autentisering”De HTTP-statusene som, når en forespørsel som bruker denne ruten mottar dem,
utløser en fornyelse av tokenet og deretter et automatisk nytt forsøk. Som
standard: 401 og 403.
To begreper, én og samme ting
Section titled “To begreper, én og samme ting”En autentiseringsforespørsel er elementet du oppretter i treet. En autentiseringsrute er det samme elementet sett fra en annen forespørsel, i velgeren som knytter det til. De to begrepene peker på den samme entiteten, på to steder i grensesnittet.
Knytte en rute til en forespørsel
Section titled “Knytte en rute til en forespørsel”I forespørselsfanen, i smartbaren, lister en velger Autentiseringsrute opp rutene i miljømappen. Standardetiketten er Ingen autentisering.
Når ruten først er knyttet til, injiseres de genererte headerne ved hver sending,
tokenet bufres til det utløper, og en 401 utløser en fornyelse du ikke merker
noe til.
Vanlige oppskrifter
Section titled “Vanlige oppskrifter”Bearer / OAuth 2 client credentials
Section titled “Bearer / OAuth 2 client credentials”Forespørsel: POST https://auth.exemple.test/oauth/token, kropp
x-www-form-urlencoded med grant_type=client_credentials,
client_id={{clientId}}, client_secret={{clientSecret}}
(der hemmeligheten er en verdi av typen Hemmelighet).
Generert header: Authorization = {{token_type}} {{access_token}}.
Utløpstid: {{expires_in}}.
Ingen forespørsel er nødvendig hvis du allerede har påloggingsdetaljene: legg rett og slett headeren på forespørselen (eller på mappen):
Authorization = Basic {{base64Encode (append (append user ":") password)}}
API-nøkkel
Section titled “API-nøkkel”En header eller en spørringsparameter er nok:
X-API-Key = {{apiKey}}, der nøkkelen er en variabel av typen Hemmelighet.
Token som hentes i to kall
Section titled “Token som hentes i to kall”Opprett et scenario: første kall, uthenting av
mellomkoden, andre kall, og deretter Sett variabel for å legge tokenet i
run-variablene. De påfølgende forespørslene i scenarioet leser det med
{{token}}.
Hva importen gjør
Section titled “Hva importen gjør”Når en spesifikasjon importeres, oversettes de deklarerte sikkerhetsskjemaene til ferdigkoblede headere eller parametere, med en miljøvariabel opprettet for deg:
| Skjema i spesifikasjonen | Hva Restorm setter opp |
|---|---|
apiKey (header eller spørring) | Et par navngitt etter skjemaet, med verdien {{<schema>}} |
http / basic | Authorization: Basic {{<schema>_credentials}} |
http / bearer, oauth2, openIdConnect | Authorization: Bearer {{<schema>_token}} |
Alt som gjenstår, er å fylle inn variabelen, eller å bytte den ut med en autentiseringsrute hvis du vil ha automatisk fornyelse.
Native påloggingsdetaljer per protokoll
Section titled “Native påloggingsdetaljer per protokoll”Noen protokoller går ikke via HTTP-headere. Påloggingsdetaljene deres er felt på forespørselen selv:
| Protokoll | Felt |
|---|---|
| MQTT | username, password, klient-ID |
| AMQP | username, password, vhost |
| Redis | password |
| Kafka | SASL-mekanisme (plain, scram-sha-256, scram-sha-512), brukernavn, passord, TLS |
| STOMP | Headerne login og passcode i CONNECT |
| gRPC | Metadata for kallet |
Hvert av disse passordene godtar en verdi av typen Hemmelighet.