Seguridad

Por defecto, todos los extremos de una aplicación VCR son de acceso público. La dirección security bloque en vcr.yml le permite controlar el acceso por ruta mediante tres niveles de acceso y la aplicación opcional de autenticación.

Se recomienda encarecidamente configurar reglas de seguridad para todos los puntos finales de su aplicación. Dejar los puntos finales sin protección expone tu aplicación a accesos no autorizados, abusos y costos inesperados. Como mínimo, establece un nivel de acceso predeterminado restrictivo y abre explícitamente sólo las rutas que deban ser públicas (como las devoluciones de llamadas de webhook de Vonage).

Niveles de acceso

Nivel Descripción
public No requiere autenticación. Cualquiera puede acceder al punto final.
private No accesible desde el exterior de la plataforma. Solo pueden llamarlo los servicios internos de VCR.
authenticated Requiere credenciales válidas de la API de Vonage en el Authorization (HTTP Basic: base64(api_key:api_secret)). La plataforma valida las credenciales antes de reenviar la solicitud a su aplicación.

Configuración

  • access establece el por defecto nivel de acceso para todas las rutas que no coincidan con una anulación.
  • override es una lista de reglas específicas para cada ruta. Las reglas se evalúan por orden; prevalece la que sea más específica.
  • auth-method es necesario cuando access es authenticated. El único valor admitido es vonage_basic.

Comodines de ruta

Comodín Partidos Ejemplo
* Un único segmento de ruta /users/*/profile coincide con /users/123/profile pero no /users/123/settings/profile
** Cualquier número de segmentos del trayecto /api/** coincide con /api/v1, /api/v1/users, /api/v1/users/123, etc.

Los puntos finales Webhook requieren acceso sin restricciones

Las devoluciones de llamadas de la plataforma de Vonage (llamadas entrantes, mensajes entrantes, recibos de entrega, etc.) se originan fuera de tu instancia. Estos puntos finales deben configurarse en publicde lo contrario, la plataforma de Vonage no podrá llegar a ellos y tus proveedores no recibirán eventos.

Cómo funciona el acceso autenticado

Cuando una solicitud llega a un authenticated path, el controlador de tráfico:

  1. Comprueba que un Authorization El encabezado está presente. Si falta, devuelve 401 Unauthorized.
  2. Comprueba las credenciales con el servicio de autenticación de Vonage y confirma que la persona que llama pertenece a la misma cuenta de Vonage que el propietario de la instancia. Si no son válidas o no coinciden, devuelve 403 Forbidden.
  3. Si la validación pasa, reenvía la solicitud a su aplicación sin cambios.

El vonage_basic utiliza la autenticación HTTP Basic. La persona que llama debe enviar su clave de API de Vonage y su secreto de API codificados como una credencial de autenticación básica:

La mayoría de los clientes HTTP gestionan esto automáticamente cuando usted proporciona un nombre de usuario y una contraseña:

El código de tu aplicación no necesita validar las credenciales por sí mismo: la plataforma aplica la autenticación antes de que la solicitud llegue a tu gestor. Si necesita identificar al autor de la llamada dentro de su gestor, la plataforma inyecta el ID de cuenta verificado a través del campo x-neru-apiaccountid de cabeza:

Herencia de métodos de autenticación

Si un override conjuntos de entrada access: authenticated pero omite auth-methodhereda el nivel superior auth-method valor. Si no se establece ninguno de los dos, la API de despliegue rechazará la configuración.