Godkendelse
Restorm har ingen dropdown med »godkendelsestype«. Den har noget mere generelt: godkendelsesanmodningen, en fuldgyldig anmodning, hvis eneste opgave er at producere headere til de andre.
Fordelen: enhver ordning kan modelleres, også de ordninger som ingen dropdown nogensinde har forudset — en udveksling i to trin, et signeret token, et hjemmelavet API. Ulempen: du skal skrive den én gang.
Opret en godkendelsesrute
Section titled “Opret en godkendelsesrute”Højreklik på en miljømappe ▸ Tilføj ▸ HTTP-godkendelsesanmodning.
Konfigurér først kaldet som enhver anden HTTP-anmodning: metode, URL, headere, body. Åbn derefter fanen Konfiguration, som rummer de tre indstillinger, der er særlige for godkendelse.
Producerede headere
Section titled “Producerede headere”Listen over de headere, som denne rute injicerer i enhver anmodning, der refererer til den. Hver værdi er et udtryk, der evalueres på svar-bodyen fra godkendelsesanmodningen.
| Header | Værdi |
|---|---|
Authorization | {{token_type}} {{access_token}} |
Udløb (sekunder)
Section titled “Udløb (sekunder)”Et udtryk, der også evalueres på svar-bodyen, og som angiver gyldighedens
længde i sekunder — typisk {{expires_in}}. Lades det tomt, udløber tokenet
aldrig af sig selv.
Fejlkoder for godkendelse
Section titled “Fejlkoder for godkendelse”De HTTP-statusser, der udløser en fornyelse af tokenet og derefter et
automatisk nyt forsøg, når en anmodning, der bruger denne rute, modtager dem.
Som standard: 401 og 403.
To ord, én ting
Section titled “To ord, én ting”En godkendelsesanmodning er det element, du opretter i træet. En godkendelsesrute er samme element set fra en anden anmodning, i den vælger der knytter den til. De to ord dækker samme entitet, to steder i brugerfladen.
Knyt en rute til en anmodning
Section titled “Knyt en rute til en anmodning”På anmodningens fane ligger der i smartbaren en vælger, Godkendelsesrute, som lister miljømappens ruter. Standardteksten er Ingen godkendelse.
Når ruten er knyttet til, injiceres de producerede headere ved hver afsendelse,
tokenet caches indtil det udløber, og en 401 udløser en fornyelse, du ikke
mærker.
Almindelige opskrifter
Section titled “Almindelige opskrifter”Bearer / OAuth 2 client credentials
Section titled “Bearer / OAuth 2 client credentials”Anmodning: POST https://auth.exemple.test/oauth/token, body
x-www-form-urlencoded med grant_type=client_credentials,
client_id={{clientId}}, client_secret={{clientSecret}} (hvor hemmeligheden
er en værdi af typen Hemmelighed).
Produceret header: Authorization = {{token_type}} {{access_token}}.
Udløb: {{expires_in}}.
Der er ingen anmodning nødvendig, hvis du allerede har loginoplysningerne: sæt blot headeren på anmodningen (eller på mappen):
Authorization = Basic {{base64Encode (append (append user ":") password)}}
API-nøgle
Section titled “API-nøgle”En header eller en query-parameter er nok: X-API-Key = {{apiKey}}, hvor
nøglen ligger i en variabel af typen Hemmelighed.
Token hentet i to kald
Section titled “Token hentet i to kald”Opret et scenarie: første kald, udtræk
mellemkoden, andet kald, og derefter Sæt variabel for at lægge tokenet i
kørselsvariablerne. Scenariets efterfølgende anmodninger læser det med
{{jeton}}.
Hvad importen gør
Section titled “Hvad importen gør”Når en specifikation importeres, oversættes de sikkerhedsordninger, den deklarerer, til færdigkoblede headere eller parametre, med en miljøvariabel oprettet til dig:
| Ordning i specifikationen | Hvad Restorm sætter op |
|---|---|
apiKey (header eller query) | Et par navngivet efter ordningen, værdi {{<schema>}} |
http / basic | Authorization: Basic {{<schema>_credentials}} |
http / bearer, oauth2, openIdConnect | Authorization: Bearer {{<schema>_token}} |
Så mangler du kun at udfylde variablen — eller at erstatte den med en godkendelsesrute, hvis du vil have automatisk fornyelse.
Protokollernes egne loginoplysninger
Section titled “Protokollernes egne loginoplysninger”Nogle protokoller går ikke gennem HTTP-headere. Deres loginoplysninger er felter på anmodningen selv:
| Protokol | Felter |
|---|---|
| MQTT | username, password, klient-id |
| AMQP | username, password, vhost |
| Redis | password |
| Kafka | SASL-mekanisme (plain, scram-sha-256, scram-sha-512), brugernavn, adgangskode, TLS |
| STOMP | CONNECT-rammens headere login og passcode |
| gRPC | Metadata på kaldet |
Hver af disse adgangskoder accepterer en værdi af typen Hemmelighed.