Saltar al contenido principal
Existen las siguientes limitaciones al usar Actions:
Para obtener más información sobre los límites de entidades, consulta: Límites de entidades de Actions.

​
Actions

  • Cada Action no debe superar los 100 kB. Cuanto mayor sea el tamaño, mayor será la latencia introducida, lo que puede afectar al rendimiento de su sistema. Este límite de tamaño no incluye ningún módulo de npm al que se haga referencia como parte de cualquier instrucción require.

​
Módulos de Actions

  • Cada módulo de Action puede tener dependencias de módulos de npm, pero no de otros módulos de Action.
  • Los módulos de Actions no tienen su propio runtime. Se ejecutan en el runtime de la Action que los incluye.
Cuando compilas un módulo de Action, Auth0 lo compila con el runtime de compilación. Sin embargo, cuando se ejecuta, usa el runtime de la Action que lo importa.Ejemplo:Si tu módulo de Action usa llamadas a la API de Node.js que están obsoletas en Node.js 22, las Actions que usan el runtime de Node.js 18 funcionarán sin problemas, pero las Actions que usan el runtime de Node.js 22 fallarán.
Escribe módulos de Actions con APIs de Node.js compatibles con todas las versiones de runtime que planeas admitir.

​
Vinculación de cuentas (setPrimaryUser)

  • primary_user_id tiene un límite de 128 caracteres
  • setPrimaryUser solo se puede llamar una vez por transacción
  • Cualquier userMetadata que se establezca en la misma Action que setPrimaryUser se descarta y se perderá. Las Actions posteriores dentro de la misma transacción conservarán userMetadata en el nuevo usuario principal.
  • setPrimaryUser no se puede usar en la misma transacción en la que una Rule establece context.primaryUser.

​
Datos en caché

  • Los elementos en caché se conservan durante un máximo de 24 horas.
  • Se pueden almacenar en caché hasta 20 entradas por Trigger.
  • Las claves de caché tienen un tamaño máximo de 64 bytes y los valores, un tamaño máximo de 4 kB.
  • El tamaño acumulado de las claves almacenadas en caché y sus valores no debe superar los 8 kB.
  • La caché debería estar disponible de forma confiable para todas las Actions del mismo trigger durante una única ejecución; sin embargo, no se garantiza en ejecuciones posteriores (como en un flujo diferente, en el inicio de sesión de otro usuario o cuando un usuario regresa de una acción de redirección).
  • Las Actions que realizan una ejecución que cede el control (como una redirección) pueden provocar que las Actions posteriores se programen en una instancia distinta con un estado de caché diferente. Los datos en caché pueden ser inconsistentes de una Action a la siguiente, incluso si se trata de la misma ejecución.

​
Ejecuciones

  • Cada ejecución de un trigger debe completarse en 20 segundos o menos; de lo contrario, el procesamiento finalizará con un error. Limitar las peticiones HTTP es la mejor manera de no superar este límite de tiempo.
  • Cada ejecución de un trigger debe completarse en 20 segundos o menos; de lo contrario, el procesamiento finalizará con un error. Para no superar este límite de tiempo, es necesario limitar los procesos de larga duración, como las peticiones HTTP salientes sin un tiempo de espera configurado. Una Action que redirige a los usuarios a una página externa tiene tiempos de espera independientes antes de la redirección y después de ella.
  • Se genera un nuevo objeto event.request cada vez que se suspende un trigger de Action y luego se reanuda (por ejemplo, debido a una redirección o a un desafío de ).

​
Registros

  • Se puede almacenar de forma persistente un máximo de 256 caracteres de la salida de console.log() por cada Action.
  • Los registros de ejecución se conservan durante 10 días.

​
Lenguajes de programación

  • No se admite TypeScript en Actions. Los archivos fuente deben estar escritos en JavaScript antes de implementarse.

​
Secretos

  • Cada clave secreta puede tener una longitud máxima de 128 caracteres.
  • Cada valor secreto puede tener una longitud máxima de 4096 caracteres.

​
Atributos SAML

  • Actions permite cambiar o agregar un máximo de 100 atributos .
  • Los nombres de los atributos SAML tienen un tamaño máximo de 1 kB.
  • Los valores de SAML tienen un tamaño máximo de 2 kB.
  • El tamaño total de las aserciones SAML tiene un máximo de 10 kB.

​
Configuración de SAML

  • audience tiene un tamaño máximo de 2 kB
  • recipient tiene un tamaño máximo de 2 kB
  • destination tiene un tamaño máximo de 2 kB
  • nameIdentifierFormat tiene un tamaño máximo de 0.5 kB
  • nameIdentifierProbes admite un máximo de 10 comprobaciones, con un tamaño máximo de 0.5 kB cada una
  • authnContextClassRef tiene un tamaño máximo de 0.5 kB
  • signingCert tiene un tamaño máximo de 4 kB
  • encryptionCert tiene un tamaño máximo de 4 kB
  • encryptionPublicKey tiene un tamaño máximo de 4 kB
  • cert tiene un tamaño máximo de 4 kB
  • key tiene un tamaño máximo de 4 kB

​
Solicitudes de servicio

​
Metadatos de la transacción

  • Solo está disponible en las Actions de post-login.
  • No se conserva una vez completado un trigger de autenticación.
  • No se puede acceder a ellos fuera de las Actions de la misma transacción.
  • Las claves están limitadas a 64 caracteres.
  • Los valores están limitados a 8 KB.
  • Los valores solo admiten los tipos string, number y boolean.
  • Tiene un tamaño total máximo de metadatos de 16 KB dentro de la misma transacción.
  • No aceptará como valores válidos números que no superen una comprobación de seguridad. El desarrollador debe serializar de forma segura los enteros no seguros. Para obtener más información, consulta safe integers.

​
Tokens de IdP externos

  • Recuperar tokens de externos del array Identities

​
Metadatos del usuario y metadatos de la aplicación

  • Cada sesión puede tener como máximo 32 kB de persistencia de metadatos del usuario y 32 kB de persistencia de metadatos de la aplicación.

​
Más información