Autentikasi

Restorm tidak memiliki menu tarik-turun “tipe autentikasi”. Yang dimilikinya lebih umum: permintaan autentikasi, yaitu sebuah permintaan tersendiri yang tugasnya menghasilkan header untuk permintaan lain.

Kelebihannya: skema apa pun dapat dimodelkan, termasuk yang tidak diantisipasi oleh menu tarik-turun mana pun — pertukaran dua tahap, token bertanda tangan, API buatan sendiri. Kekurangannya: Anda harus menuliskannya sekali.

Membuat rute autentikasi

Klik kanan pada sebuah folder variabel ▸ Tambah ▸ Permintaan autentikasi.

Konfigurasikan terlebih dahulu panggilannya seperti permintaan HTTP biasa: metode, URL, header, body. Lalu bukalah tab Konfigurasi-nya, yang memuat tiga setelan khas autentikasi.

Header yang dihasilkan

Daftar header yang akan disuntikkan rute ini ke dalam setiap permintaan yang merujuknya. Setiap nilainya adalah ekspresi yang dievaluasi terhadap body respons dari permintaan autentikasi tersebut.

Header	Nilai
Authorization	{{token_type}} {{access_token}}

Masa berlaku (detik)

Sebuah ekspresi, juga dievaluasi terhadap body respons, yang memberikan durasi keabsahan dalam detik — biasanya {{expires_in}}. Bila dibiarkan kosong, tokennya tidak pernah kedaluwarsa dengan sendirinya.

Kode galat autentikasi

Status HTTP yang, bila diterima oleh sebuah permintaan yang memakai rute ini, memicu pembaruan token lalu percobaan ulang otomatis. Secara bawaan: 401 dan 403.

Dua istilah, satu hal yang sama

Permintaan autentikasi adalah elemen yang Anda buat di dalam pohon. Rute autentikasi adalah elemen yang sama, dilihat dari permintaan lain, di dalam pemilih yang melampirkannya. Kedua istilah itu menunjuk entitas yang sama, di dua tempat berbeda dalam antarmuka.

Melampirkan rute ke sebuah permintaan

Pada tab permintaan, di dalam smartbar, sebuah pemilih Rute autentikasi mendaftar rute-rute milik folder variabel. Label bawaannya adalah Tanpa autentikasi.

Setelah dilampirkan, header yang dihasilkan disuntikkan pada setiap pengiriman, tokennya disimpan dalam cache hingga masa berlakunya habis, dan sebuah 401 memicu pembaruan yang tak terlihat.

Resep yang lazim

Bearer / OAuth 2 client credentials

Permintaan: POST https://auth.exemple.test/oauth/token, body x-www-form-urlencoded dengan grant_type=client_credentials, client_id={{clientId}}, client_secret={{clientSecret}} (dengan rahasianya berupa nilai bertipe Rahasia).

Header yang dihasilkan: Authorization = {{token_type}} {{access_token}}. Masa berlaku: {{expires_in}}.

Basic

Tidak ada permintaan yang diperlukan jika Anda sudah memiliki kredensialnya: cukup pasang headernya pada permintaan (atau pada foldernya):

Authorization = Basic {{base64Encode (append (append user ":") password)}}

Kunci API

Sebuah header atau parameter kueri sudah cukup: X-API-Key = {{apiKey}}, dengan kuncinya berupa variabel bertipe Rahasia.

Token yang diperoleh lewat dua panggilan

Buatlah sebuah skenario: panggilan pertama, ekstraksi kode antara, panggilan kedua, lalu Definisikan variabel untuk menaruh tokennya di dalam variabel run. Permintaan berikutnya dalam skenario itu membacanya dengan {{jeton}}.

Apa yang dilakukan impor

Saat mengimpor sebuah spesifikasi, skema keamanan yang dideklarasikan diterjemahkan menjadi header atau parameter yang sudah terpasang, lengkap dengan variabel lingkungan yang dibuatkan untuk Anda:

Skema di dalam spesifikasi	Yang dipasang Restorm
apiKey (header atau kueri)	Sebuah pasangan yang dinamai menurut skemanya, bernilai {{<schema>}}
http / basic	Authorization: Basic {{<schema>_credentials}}
http / bearer, oauth2, openIdConnect	Authorization: Bearer {{<schema>_token}}

Anda tinggal mengisi variabelnya, atau menggantinya dengan sebuah rute autentikasi bila menginginkan pembaruan otomatis.

Koleksi Postman, Insomnia, dan Bruno

Blok autentikasi dari alat-alat tersebut dibaca dan didokumentasikan saat impor (dengan nilai sensitif disamarkan), tetapi tidak dikonversi menjadi kredensial yang dapat dieksekusi: buatlah kembali sebuah rute autentikasi.

Kredensial bawaan tiap protokol

Sebagian protokol tidak melewati header HTTP. Kredensialnya berupa kolom pada permintaan itu sendiri:

Protokol	Kolom
MQTT	username, password, pengenal klien
AMQP	username, password, vhost
Redis	password
Kafka	Mekanisme SASL (plain, scram-sha-256, scram-sha-512), kredensial, kata sandi, TLS
STOMP	Header login dan passcode pada CONNECT
gRPC	Metadata panggilan

Masing-masing kata sandi tersebut menerima nilai bertipe Rahasia.