Autenticazione

Restorm non ha un menu a tendina «tipo di autenticazione». Ha qualcosa di più generale: la richiesta di autenticazione, una richiesta a tutti gli effetti il cui ruolo è produrre header per le altre.

Il vantaggio: qualsiasi schema è modellabile, compresi quelli che nessun elenco a tendina prevede — uno scambio in due tempi, un token firmato, un’API sviluppata in casa. Lo svantaggio: va scritto una volta.

Creare una rotta di autenticazione

Clic destro su una cartella di variabili ▸ Aggiungi ▸ Richiesta di autenticazione.

Prima si configura la chiamata come qualsiasi richiesta HTTP: metodo, URL, header, corpo. Poi si apre la scheda Configurazione, che ospita le tre impostazioni specifiche dell’autenticazione.

Header prodotti

L’elenco degli header che questa rotta inietterà in ogni richiesta che la referenzia. Ogni valore è un’espressione valutata sul corpo della risposta della richiesta di autenticazione.

Header	Valore
Authorization	{{token_type}} {{access_token}}

Scadenza (secondi)

Un’espressione, anch’essa valutata sul corpo della risposta, che indica la durata di validità in secondi — tipicamente {{expires_in}}. Se lasciata vuota, il token non scade mai da solo.

Codici di errore di autenticazione

Gli stati HTTP che, se ricevuti da una richiesta che usa questa rotta, innescano un rinnovo del token seguito da un nuovo tentativo automatico. Per impostazione predefinita: 401 e 403.

Due termini, una sola cosa

Una richiesta di autenticazione è l’elemento che si crea nell’albero. Una rotta di autenticazione è quello stesso elemento visto da un’altra richiesta, nel selettore che lo collega. I due termini designano la stessa entità, in due punti dell’interfaccia.

Collegare una rotta a una richiesta

Nella scheda della richiesta, all’interno della smartbar, un selettore Rotta di autenticazione elenca le rotte della cartella di variabili. L’etichetta predefinita è Nessuna autenticazione.

Una volta collegata, gli header prodotti vengono iniettati a ogni invio, il token viene messo in cache fino alla scadenza e un 401 provoca un rinnovo trasparente.

Ricette comuni

Bearer / OAuth 2 client credentials

Richiesta: POST https://auth.exemple.test/oauth/token, corpo x-www-form-urlencoded con grant_type=client_credentials, client_id={{clientId}}, client_secret={{clientSecret}} (dove il segreto è un valore di tipo Segreto).

Header prodotto: Authorization = {{token_type}} {{access_token}}. Scadenza: {{expires_in}}.

Basic

Non serve alcuna richiesta se si dispone già delle credenziali: basta impostare l’header sulla richiesta (o sulla cartella):

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

Chiave di API

È sufficiente un header o un parametro di query: X-API-Key = {{apiKey}}, dove la chiave è una variabile di tipo Segreto.

Token ottenuto con due chiamate

Occorre creare uno scenario: prima chiamata, estrazione del codice intermedio, seconda chiamata, poi Definisci variabile per impostare il token nelle variabili di run. Le richieste successive dello scenario lo leggono con {{jeton}}.

Che cosa fa l’importazione

All’importazione di una specifica, gli schemi di sicurezza dichiarati vengono tradotti in header o parametri precablati, con una variabile d’ambiente creata automaticamente:

Schema nella specifica	Ciò che Restorm imposta
apiKey (header o query)	Una coppia denominata come lo schema, valore {{<schema>}}
http / basic	Authorization: Basic {{<schema>_credentials}}
http / bearer, oauth2, openIdConnect	Authorization: Bearer {{<schema>_token}}

Non resta che compilare la variabile, oppure sostituirla con una rotta di autenticazione se si desidera il rinnovo automatico.

Collezioni Postman, Insomnia e Bruno

I blocchi di autenticazione di questi strumenti vengono letti e documentati all’importazione (con i valori sensibili mascherati), ma non vengono convertiti in credenziali eseguibili: occorre ricreare una rotta di autenticazione.

Credenziali native per protocollo

Alcuni protocolli non passano da header HTTP. Le loro credenziali sono campi della richiesta stessa:

Protocollo	Campi
MQTT	username, password, identificatore client
AMQP	username, password, vhost
Redis	password
Kafka	Meccanismo SASL (plain, scram-sha-256, scram-sha-512), identificativo, password, TLS
STOMP	Header login e passcode del CONNECT
gRPC	Metadati della chiamata

Ognuna di queste password accetta un valore di tipo Segreto.