Saltar al contenido principal
Los scripts de Action se ejecutan como una serie de funciones de JavaScript invocadas en una instancia de un contenedor Webtask sin servidor. Como parte de ello, se proporciona un entorno específico, junto con una serie de artefactos suministrados tanto por el contenedor de Webtask como por el de Auth0 (su inquilino de Auth0).

​
módulos de npm

Los contenedores Webtask sin servidor de Auth0 pueden utilizar una amplia gama de módulos de npm; los módulos de npm no solo reducen el tamaño total del código de implementación del script de Action, sino que también proporcionan acceso a una amplia variedad de funcionalidades predefinidas. De forma predeterminada, se admite de fábrica una amplia lista de módulos de npm disponibles públicamente. Esta lista se ha recopilado y revisado para detectar posibles problemas de seguridad. Para ver qué módulos de npm se admiten, consulte Can I require: Auth0 Extensibility. Si necesita un módulo de npm que no se admita de fábrica, puede enviar una solicitud a través del portal de Auth0 Extensibility o por medio de su representante de Auth0. Auth0 evaluará su solicitud para determinar si es adecuada; si necesita escalar una solicitud sin resolver, abra un ticket de soporte a través del portal de soporte de Auth0. Actualmente, Auth0 no admite el uso de módulos de npm de repositorios privados.

​
Variables

Los scripts de Action de Auth0 admiten variables de entorno, a las que se accede a través del objeto configuration, disponible globalmente. El objeto configuration debe tratarse como de solo lectura y usarse para almacenar información confidencial, como credenciales o claves de API para acceder a almacenes de identidad externos. Esto evita tener valores sensibles para la seguridad codificados de forma rígida en un script de Action. El objeto configuration también puede usarse para respaldar las estrategias de prácticas recomendadas del ciclo de vida del desarrollo de software (SDLC) que emplee, como configurar varios entornos, ya que le permite definir variables con valores específicos del inquilino. Esto evita valores codificados de forma rígida en un script de Action, que pueden cambiar según el inquilino que lo ejecute.

​
objeto global

Los contenedores serverless de Webtask de Auth0 se aprovisionan desde un grupo asociado a cada inquilino de Auth0. Cada instancia de contenedor pone a disposición un objeto global al que se puede acceder desde todos los scripts de Action que se ejecutan en ella (la instancia de contenedor). El objeto global actúa como una variable global exclusiva del contenedor y puede usarse para definir información, o incluso funciones, que puedan utilizarse en todos los scripts de Action que se ejecutan en él (la instancia de contenedor). Esto significa que el objeto global puede usarse para almacenar en caché recursos costosos, siempre que esos recursos no sean específicos de un usuario. Por ejemplo, se podría almacenar un para una API de terceros (por ejemplo, de registro) que ofrezca funcionalidad no específica de un usuario. O bien, podría usarse para almacenar un Token de acceso para su propia API no específica de un usuario, definida en Auth0 y obtenida mediante el flujo Client Credentials.
Un script de Action puede ejecutarse en cualquiera de las instancias de contenedor que ya estén en ejecución o en una instancia de contenedor recién creada (que posteriormente podría añadirse al grupo). No existe afinidad de contenedor para la ejecución de scripts de Action en Auth0. Esto significa que debe evitar almacenar información específica de un usuario en el objeto global y asegurarse siempre de que cualquier declaración realizada dentro del objeto global también contemple la inicialización.
Cada vez que se recicla un contenedor de Webtask, o cada vez que se crea una nueva instancia de un contenedor de Webtask, el objeto global que define se restablece. Por lo tanto, cualquier asignación dentro del objeto global asociado a un contenedor también debe incluir la inicialización. Para ofrecer flexibilidad de rendimiento, los contenedores serverless de Webtask se aprovisionan en Auth0 de forma ad hoc y también están sujetos a diversas políticas de reciclaje. En general, recomendamos no considerar que la vida útil de un objeto global sea superior a 20 minutos.

​
Lista de comprobación del entorno para conexiones de base de datos personalizadas

  • Asegúrate de que tu base de datos tenga los campos adecuados para almacenar atributos del perfil de usuario, como id, nickname, email y password. Para obtener más información sobre el esquema del perfil de usuario de Auth0 y los campos esperados, consulta Normalized User Profiles. Para obtener más información sobre cómo actualizar perfiles de usuario, consulta Update User Profiles Using Your Database.
  • Puedes usar los errores devueltos por tu conexión de base de datos personalizada para solucionar problemas.
  • Auth0 usará la propiedad id (o, alternativamente, user_id) del perfil de usuario devuelto para identificar al usuario. Si usas varias conexiones de base de datos personalizadas, el valor de id debe ser único en todas las conexiones de base de datos personalizadas para evitar colisiones de ID de usuario. Nuestra recomendación es anteponer al valor de id el nombre de la conexión (sin espacios en blanco). Para obtener más información sobre los ID de usuario, consulta Identify Users.
  • La latencia será mayor en comparación con los almacenes de usuarios alojados en Auth0.
  • La base de datos o el servicio debe ser accesible desde los servidores de Auth0. Tendrás que configurar conexiones entrantes si tu almacén está detrás de un firewall.

​
Probar una versión específica del entorno de ejecución

La versión del entorno de ejecución para los scripts personalizados de Database se define en Dashboard > Settings > Advanced, dentro de la sección Extensibility. Siga estos pasos para probar un script personalizado de Database en una versión específica del entorno de ejecución:
  1. Vaya a Authentication > Database.
  2. Seleccione la conexión de Database en la que definió un script personalizado.
  3. En la página de la conexión de base de datos seleccionada, seleccione la pestaña Custom Database.
  4. Desplácese hasta la sección Database Action Scripts de la página.
  5. Seleccione el script concreto que desea verificar (por ejemplo, Login, Create, etc.) en la pestaña correspondiente.
  6. Seleccione Save and Try. Se abrirá una ventana modal con parámetros de prueba específicos y detalles de contexto de ejemplo. Actualícelos según sea necesario.
  7. Seleccione Try en la ventana modal para abrir un selector desplegable de una versión específica de Node.
  8. La prueba se ejecutará al seleccionar la versión de Node deseada y los resultados aparecerán en un mensaje en la misma pantalla.

​
Más información