Autenticación
Restorm no tiene un menú desplegable de «tipo de autenticación». Tiene algo más general: la petición de autenticación, una petición de pleno derecho cuyo papel es producir cabeceras para las demás.
La ventaja: se puede modelar cualquier esquema, incluidos los que ninguna lista desplegable prevé —un intercambio en dos tiempos, un token firmado, una API propia—. El inconveniente: hay que escribirlo una vez.
Crear una ruta de autenticación
Section titled “Crear una ruta de autenticación”Clic derecho sobre una carpeta de variables ▸ Añadir ▸ Petición de autenticación.
Configure primero la llamada como cualquier petición HTTP: método, URL, cabeceras, cuerpo. Después abra su pestaña Configuración, que contiene los tres ajustes propios de la autenticación.
Cabeceras producidas
Section titled “Cabeceras producidas”La lista de cabeceras que esta ruta inyectará en toda petición que la referencie. Cada valor es una expresión evaluada sobre el cuerpo de la respuesta de la petición de autenticación.
| Cabecera | Valor |
|---|---|
Authorization | {{token_type}} {{access_token}} |
Caducidad (segundos)
Section titled “Caducidad (segundos)”Una expresión, también evaluada sobre el cuerpo de la respuesta, que indica la
duración de validez en segundos, normalmente {{expires_in}}. Si se deja vacía, el
token no caduca nunca por sí solo.
Códigos de error de autenticación
Section titled “Códigos de error de autenticación”Los estados HTTP que, al recibirse en una petición que usa esta ruta, desencadenan
una renovación del token seguida de un reintento automático. Por defecto: 401
y 403.
Dos términos, una sola cosa
Section titled “Dos términos, una sola cosa”Una petición de autenticación es el elemento que usted crea en el árbol. Una ruta de autenticación es ese mismo elemento visto desde otra petición, en el selector que lo asocia. Los dos términos designan la misma entidad en dos lugares de la interfaz.
Asociar una ruta a una petición
Section titled “Asociar una ruta a una petición”En la pestaña de la petición, dentro de la smartbar, un selector Ruta de autenticación enumera las rutas de la carpeta de variables. La etiqueta por defecto es Sin autenticación.
Una vez asociada, las cabeceras producidas se inyectan en cada envío, el token se
guarda en caché hasta su caducidad y un 401 provoca una renovación transparente.
Recetas habituales
Section titled “Recetas habituales”Bearer / OAuth 2 client credentials
Section titled “Bearer / OAuth 2 client credentials”Petición: POST https://auth.exemple.test/oauth/token, cuerpo
x-www-form-urlencoded con grant_type=client_credentials,
client_id={{clientId}}, client_secret={{clientSecret}}
(siendo el secreto un valor de tipo Secreto).
Cabecera producida: Authorization = {{token_type}} {{access_token}}.
Caducidad: {{expires_in}}.
No hace falta ninguna petición si ya tiene las credenciales: basta con poner la cabecera en la petición (o en la carpeta):
Authorization = Basic {{base64Encode (append (append user ":") password)}}
Clave de API
Section titled “Clave de API”Basta con una cabecera o un parámetro de consulta:
X-API-Key = {{apiKey}}, siendo la clave una variable de tipo Secreto.
Token obtenido en dos llamadas
Section titled “Token obtenido en dos llamadas”Cree un escenario: primera llamada, extracción
del código intermedio, segunda llamada y después Definir variable para colocar el
token en las variables de ejecución. Las peticiones siguientes del escenario lo
leen con {{jeton}}.
Lo que hace la importación
Section titled “Lo que hace la importación”Al importar una especificación, los esquemas de seguridad declarados se traducen a cabeceras o parámetros preconfigurados, con una variable de entorno creada para usted:
| Esquema en la especificación | Lo que Restorm coloca |
|---|---|
apiKey (cabecera o consulta) | Un par nombrado según el esquema, con valor {{<schema>}} |
http / basic | Authorization: Basic {{<schema>_credentials}} |
http / bearer, oauth2, openIdConnect | Authorization: Bearer {{<schema>_token}} |
Solo le queda rellenar la variable, o sustituirla por una ruta de autenticación si quiere la renovación automática.
Credenciales nativas por protocolo
Section titled “Credenciales nativas por protocolo”Algunos protocolos no pasan por cabeceras HTTP. Sus credenciales son campos de la propia petición:
| Protocolo | Campos |
|---|---|
| MQTT | username, password, identificador de cliente |
| AMQP | username, password, vhost |
| Redis | password |
| Kafka | Mecanismo SASL (plain, scram-sha-256, scram-sha-512), identificador, contraseña, TLS |
| STOMP | Cabeceras login y passcode del CONNECT |
| gRPC | Metadatos de la llamada |
Cada una de estas contraseñas acepta un valor de tipo Secreto.