Skip to main content
Les limitations suivantes s’appliquent à l’utilisation d’Auth0 Actions :
Pour en savoir plus sur les limites des entités, consultez : Limites des entités d’Auth0 Actions.

​
Actions

  • Chaque Action ne doit pas dépasser 100 kB. Plus sa taille est grande, plus elle ajoute de la latence, ce qui peut nuire aux performances de votre système. Cette limite de taille n’inclut aucun module npm pouvant être référencé dans une instruction require.

​
Modules Actions

  • Chaque module Action peut avoir des dépendances vers des modules NPM, mais pas vers d’autres modules Actions.
  • Les modules Actions n’ont pas leur propre runtime. Ils s’exécutent dans le runtime de l’Action qui les inclut.
Lorsque vous créez un module Action, Auth0 le génère avec le runtime du builder. Toutefois, lorsque le module est exécuté, il utilise le runtime de l’Action qui l’importe.Exemple :Si votre module Action utilise des appels d’API Node.js dépréciés dans Node.js 22, les Actions utilisant le runtime Node.js 18 fonctionneront très bien, mais les Actions utilisant le runtime Node.js 22 échoueront.
Écrivez les modules Actions à l’aide d’API Node.js compatibles avec toutes les versions de runtime que vous prévoyez prendre en charge.

​
Liaison de comptes (setPrimaryUser)

  • primary_user_id est limité à 128 caractères
  • setPrimaryUser ne peut être appelé qu’une seule fois par transaction
  • Toute valeur userMetadata définie dans la même Action que setPrimaryUser est ignorée et sera perdue. Les Actions subséquentes dans la même transaction conserveront userMetadata pour le nouvel utilisateur principal.
  • setPrimaryUser ne peut pas être utilisé dans la même transaction dans laquelle une Rule définit context.primaryUser.

​
Données mises en cache

  • Les éléments mis en cache sont enregistrés pendant un maximum de 24 heures.
  • Un maximum de 20 entrées peut être mis en cache par Trigger.
  • Les clés de cache ont une taille maximale de 64 octets, et les valeurs, une taille maximale de 4 kB.
  • La taille cumulée des clés mises en cache et de leurs valeurs ne doit pas dépasser 8 kB.
  • Le cache devrait être accessible de manière fiable à toutes les Actions d’un même déclencheur au cours d’une seule exécution; toutefois, cela n’est pas garanti pour les exécutions suivantes (par exemple, dans un flow différent, lors d’une autre connexion d’utilisateur ou lorsqu’un utilisateur revient après une action de redirection).
  • Les Actions qui effectuent une exécution avec restitution du contrôle (comme une redirection) peuvent faire en sorte que les actions suivantes soient planifiées sur une instance distincte avec un état de cache différent. Les données mises en cache peuvent être incohérentes d’une Action à l’autre, même s’il s’agit de la même exécution.

​
Exécutions

  • Chaque exécution d’un déclencheur doit se terminer en 20 secondes ou moins, sinon le traitement se soldera par une erreur. La meilleure façon de respecter ce délai est de limiter les requêtes HTTP.
  • Chaque exécution d’un déclencheur doit se terminer en 20 secondes ou moins, sinon le traitement se soldera par une erreur. Pour respecter ce délai, il faut limiter les processus de longue durée, comme les requêtes HTTP sortantes sans délai d’expiration. Une Action qui redirige les utilisateurs vers une page externe a un délai d’expiration distinct avant la redirection et un autre après.
  • Un nouvel objet event.request est généré chaque fois qu’un déclencheur Actions est suspendu, puis repris par la suite (par exemple, en raison d’une redirection ou d’une ).

​
Journaux

  • Un maximum de 256 caractères peut être enregistré de façon permanente pour la sortie console.log() de chaque Action.
  • Les journaux d’exécution sont conservés pendant 10 jours.

​
Langages de programmation

  • Nous ne prenons pas en charge TypeScript dans les Actions. Les fichiers source doivent être rédigés en JavaScript avant d’être déployés.

​
Secrets

  • La clé de chaque secret peut contenir au maximum 128 caractères.
  • La valeur de chaque secret peut contenir au maximum 4096 caractères.

​
Attributs SAML

  • Un maximum de 100 attributs peuvent être modifiés ou ajoutés par Actions.
  • Les noms d’attribut SAML ont une taille maximale de 1kB.
  • Les valeurs SAML ont une taille maximale de 2kB.
  • La taille totale des assertions SAML ne peut pas dépasser 10kB.

​
Configuration de SAML

  • audience a une taille maximale de 2 kB
  • recipient a une taille maximale de 2 kB
  • destination a une taille maximale de 2 kB
  • nameIdentifierFormat a une taille maximale de 0,5 kB
  • nameIdentifierProbes a un maximum de 10 sondes, d’une taille maximale de 0,5 kB chacune
  • authnContextClassRef a une taille maximale de 0,5 kB
  • signingCert a une taille maximale de 4 kB
  • encryptionCert a une taille maximale de 4 kB
  • encryptionPublicKey a une taille maximale de 4 kB
  • cert a une taille maximale de 4 kB
  • key a une taille maximale de 4 kB

​
Requêtes de service

​
Métadonnées de transaction

  • Sont disponibles uniquement dans les Actions post-login.
  • Ne sont pas enregistrées au-delà de l’exécution d’un déclencheur d’authentification.
  • Ne sont pas accessibles à l’extérieur des Actions au sein d’une même transaction.
  • Les clés sont limitées à 64 caractères.
  • Les valeurs sont limitées à 8 KB.
  • Les valeurs ne prennent en charge que les types string, number et boolean.
  • Ont une taille totale maximale de 16 KB au sein d’une même transaction.
  • N’acceptent pas comme valeurs valides les nombres qui échouent à la vérification de sûreté. Les valeurs entières non sûres doivent être sérialisées de façon sûre par le développeur. Pour en savoir plus, consultez la documentation sur les entiers sûrs.

​
Jetons provenant d’IdP externes

  • Récupération des jetons d’ externes à partir du tableau Identities

​
Métadonnées utilisateur et métadonnées d’application

  • Chaque session peut comporter au maximum 32 kB de métadonnées utilisateur et 32 kB de métadonnées d’application.

​
En savoir plus