Uwierzytelnianie
Restorm nie ma listy rozwijanej „typ uwierzytelniania”. Ma coś bardziej ogólnego: żądanie uwierzytelniania, czyli pełnoprawne żądanie, którego rolą jest wytwarzanie nagłówków dla pozostałych.
Zaleta: można odwzorować dowolny schemat, w tym taki, którego nie przewiduje żadna lista rozwijana — wymianę w dwóch etapach, podpisany token, autorskie API. Wada: trzeba go raz opisać.
Tworzenie trasy uwierzytelniania
Section titled “Tworzenie trasy uwierzytelniania”Kliknięcie prawym przyciskiem na folderze zmiennych ▸ Dodaj ▸ Żądanie uwierzytelniania.
Najpierw należy skonfigurować wywołanie jak każde inne żądanie HTTP: metoda, adres URL, nagłówki, treść. Następnie otwiera się jego zakładkę Konfiguracja, która zawiera trzy ustawienia właściwe dla uwierzytelniania.
Wytwarzane nagłówki
Section titled “Wytwarzane nagłówki”Lista nagłówków, które ta trasa wstrzyknie do każdego żądania odwołującego się do niej. Każda wartość jest wyrażeniem obliczanym na treści odpowiedzi żądania uwierzytelniania.
| Nagłówek | Wartość |
|---|---|
Authorization | {{token_type}} {{access_token}} |
Wygaśnięcie (sekundy)
Section titled “Wygaśnięcie (sekundy)”Wyrażenie, również obliczane na treści odpowiedzi, które podaje czas ważności
w sekundach — zazwyczaj {{expires_in}}. Pozostawione puste oznacza, że token
nigdy nie wygasa samodzielnie.
Kody błędów uwierzytelniania
Section titled “Kody błędów uwierzytelniania”Statusy HTTP, które — otrzymane przez żądanie korzystające z tej trasy —
wywołują odnowienie tokenu, a następnie automatyczną ponowną próbę.
Domyślnie: 401 i 403.
Dwa terminy, jedna rzecz
Section titled “Dwa terminy, jedna rzecz”Żądanie uwierzytelniania to element tworzony w drzewie. Trasa uwierzytelniania to ten sam element widziany z innego żądania, w selektorze, który go dołącza. Oba terminy oznaczają tę samą encję, w dwóch miejscach interfejsu.
Dołączanie trasy do żądania
Section titled “Dołączanie trasy do żądania”W zakładce żądania, w smartbarze, selektor Trasa uwierzytelniania wymienia trasy danego folderu zmiennych. Domyślna etykieta to Brak uwierzytelniania.
Po dołączeniu wytwarzane nagłówki są wstrzykiwane przy każdym wysłaniu, token
jest przechowywany w pamięci podręcznej do momentu wygaśnięcia, a odpowiedź
401 powoduje niewidoczne dla użytkownika odnowienie.
Typowe przepisy
Section titled “Typowe przepisy”Bearer / OAuth 2 client credentials
Section titled “Bearer / OAuth 2 client credentials”Żądanie: POST https://auth.exemple.test/oauth/token, treść
x-www-form-urlencoded z grant_type=client_credentials,
client_id={{clientId}}, client_secret={{clientSecret}}
(gdzie sekret jest wartością typu Sekret).
Wytwarzany nagłówek: Authorization = {{token_type}} {{access_token}}.
Wygaśnięcie: {{expires_in}}.
Jeśli dane uwierzytelniające są już znane, żadne żądanie nie jest potrzebne — wystarczy ustawić nagłówek na żądaniu (albo na folderze):
Authorization = Basic {{base64Encode (append (append user ":") password)}}
Klucz API
Section titled “Klucz API”Wystarczy nagłówek lub parametr zapytania:
X-API-Key = {{apiKey}}, gdzie klucz jest zmienną typu Sekret.
Token pobierany dwoma wywołaniami
Section titled “Token pobierany dwoma wywołaniami”Należy utworzyć scenariusz: pierwsze
wywołanie, wyodrębnienie kodu pośredniego, drugie wywołanie, a następnie akcja
Ustaw zmienną, aby umieścić token w zmiennych uruchomienia. Kolejne żądania
scenariusza odczytują go przez {{jeton}}.
Co robi import
Section titled “Co robi import”Przy imporcie specyfikacji zadeklarowane schematy zabezpieczeń są tłumaczone na wstępnie podłączone nagłówki lub parametry, wraz z utworzoną zmienną środowiskową:
| Schemat w specyfikacji | Co ustawia Restorm |
|---|---|
apiKey (nagłówek lub zapytanie) | Parę nazwaną według schematu, wartość {{<schema>}} |
http / basic | Authorization: Basic {{<schema>_credentials}} |
http / bearer, oauth2, openIdConnect | Authorization: Bearer {{<schema>_token}} |
Pozostaje jedynie wypełnić zmienną albo zastąpić ją trasą uwierzytelniania, gdy potrzebne jest automatyczne odnawianie.
Natywne dane uwierzytelniające poszczególnych protokołów
Section titled “Natywne dane uwierzytelniające poszczególnych protokołów”Część protokołów nie korzysta z nagłówków HTTP. Ich dane uwierzytelniające są polami samego żądania:
| Protokół | Pola |
|---|---|
| MQTT | username, password, identyfikator klienta |
| AMQP | username, password, vhost |
| Redis | password |
| Kafka | Mechanizm SASL (plain, scram-sha-256, scram-sha-512), identyfikator, hasło, TLS |
| STOMP | Nagłówki login i passcode polecenia CONNECT |
| gRPC | Metadane wywołania |
Każde z tych haseł przyjmuje wartość typu Sekret.