Vërtetimi
Restorm nuk ka një menu rënëse «tipi i vërtetimit». Ai ka diçka më të përgjithshme: kërkesën e vërtetimit, një kërkesë më vete roli i së cilës është të prodhojë koka për të tjerat.
Përparësia: modelohet çdo skemë, përfshirë ato që asnjë menu rënëse nuk i parashikon — një shkëmbim në dy faza, një token i nënshkruar, një API e brendshme. Disavantazhi: duhet shkruar një herë.
Krijimi i një rruge vërtetimi
Section titled “Krijimi i një rruge vërtetimi”Klik me të djathtën mbi një dosje variablash ▸ Shto ▸ Kërkesë vërtetimi.
Konfiguroni fillimisht thirrjen si çdo kërkesë tjetër HTTP: metodë, URL, koka, trup. Pastaj hapni skedën e saj Konfigurimi, që mban tri rregullimet specifike të vërtetimit.
Kokat e prodhuara
Section titled “Kokat e prodhuara”Lista e kokave që kjo rrugë do të injektojë në çdo kërkesë që e referencon. Çdo vlerë është një shprehje e vlerësuar mbi trupin e përgjigjes të kërkesës së vërtetimit.
| Koka | Vlera |
|---|---|
Authorization | {{token_type}} {{access_token}} |
Skadimi (sekonda)
Section titled “Skadimi (sekonda)”Një shprehje, gjithashtu e vlerësuar mbi trupin e përgjigjes, që jep kohën e
vlefshmërisë në sekonda — zakonisht {{expires_in}}. Nëse lihet bosh, token-i
nuk skadon kurrë vetvetiu.
Kodet e gabimit të vërtetimit
Section titled “Kodet e gabimit të vërtetimit”Statuset HTTP që, kur merren nga një kërkesë që përdor këtë rrugë, shkaktojnë
një rinovim të token-it dhe pastaj një ritentativë automatike. Si
parazgjedhje: 401 dhe 403.
Dy terma, një gjë e vetme
Section titled “Dy terma, një gjë e vetme”Një kërkesë vërtetimi është elementi që krijoni në pemë. Një rrugë vërtetimi është po ai element i parë nga një kërkesë tjetër, në zgjedhësin që e bashkëngjit atë. Të dy termat i referohen së njëjtës entitet, në dy vende të ndërfaqes.
Bashkëngjitja e një rruge te një kërkesë
Section titled “Bashkëngjitja e një rruge te një kërkesë”Në skedën e kërkesës, brenda smartbar-it, një zgjedhës Rruga e vërtetimit rendit rrugët e dosjes së variablave. Etiketa e parazgjedhur është Pa vërtetim.
Sapo bashkëngjitet, kokat e prodhuara injektohen në çdo dërgim, token-i ruhet
në memorie deri në skadimin e tij dhe një 401 shkakton një rinovim
transparent.
Receta të zakonshme
Section titled “Receta të zakonshme”Bearer / OAuth 2 client credentials
Section titled “Bearer / OAuth 2 client credentials”Kërkesa: POST https://auth.exemple.test/oauth/token, trup
x-www-form-urlencoded me grant_type=client_credentials,
client_id={{clientId}}, client_secret={{clientSecret}}
(ku sekreti është një vlerë e tipit Sekret).
Koka e prodhuar: Authorization = {{token_type}} {{access_token}}.
Skadimi: {{expires_in}}.
Nuk nevojitet asnjë kërkesë nëse i keni tashmë kredencialet: vendosni thjesht kokën mbi kërkesën (ose mbi dosjen):
Authorization = Basic {{base64Encode (append (append user ":") password)}}
Çelës API
Section titled “Çelës API”Mjafton një kokë ose një parametër kërkese:
X-API-Key = {{apiKey}}, ku çelësi është një variabël e tipit Sekret.
Token i marrë me dy thirrje
Section titled “Token i marrë me dy thirrje”Krijoni një skenar: thirrja e parë,
nxjerrja e kodit të ndërmjetëm, thirrja e dytë, pastaj Përcakto variabël për
ta vendosur token-in te variablat e ekzekutimit. Kërkesat pasuese të skenarit e
lexojnë atë me {{jeton}}.
Çfarë bën importimi
Section titled “Çfarë bën importimi”Gjatë importimit të një specifikimi, skemat e sigurisë të deklaruara përkthehen në koka ose parametra të parangjitur, me një variabël mjedisi të krijuar për ju:
| Skema në specifikim | Çfarë vendos Restorm |
|---|---|
apiKey (kokë ose kërkesë) | Një çift i emërtuar sipas skemës, me vlerë {{<schema>}} |
http / basic | Authorization: Basic {{<schema>_credentials}} |
http / bearer, oauth2, openIdConnect | Authorization: Bearer {{<schema>_token}} |
Ju mbetet vetëm ta plotësoni variablën, ose ta zëvendësoni me një rrugë vërtetimi nëse doni rinovimin automatik.
Kredenciale vendase sipas protokollit
Section titled “Kredenciale vendase sipas protokollit”Disa protokolle nuk kalojnë përmes kokash HTTP. Kredencialet e tyre janë fusha të vetë kërkesës:
| Protokolli | Fushat |
|---|---|
| MQTT | username, password, identifikuesi i klientit |
| AMQP | username, password, vhost |
| Redis | password |
| Kafka | Mekanizmi SASL (plain, scram-sha-256, scram-sha-512), identifikues, fjalëkalim, TLS |
| STOMP | Kokat login dhe passcode të CONNECT |
| gRPC | Metatë dhënat e thirrjes |
Secili prej këtyre fjalëkalimeve pranon një vlerë të tipit Sekret.