Passer au contenu principal
Dans le cadre de notre vision à long terme pour l’extensibilité d’Auth0 au moyen de code personnalisé, nous avons affiné et simplifié les modèles de programmation introduits pendant la période bêta d’Actions. La création d’Actions se fait désormais de façon plus cohérente et plus prévisible dans l’ensemble des Triggers. Les données d’événement sont maintenant davantage alignées sur l’Auth0 Management API et sur d’autres aspects de la plateforme Auth0. La modification du comportement de la transaction au moyen de code personnalisé s’effectue désormais toujours en appelant des méthodes d’un nouvel argument api. La migration d’une Action créée avant la disponibilité générale (GA) devrait généralement suivre les étapes suivantes :
  1. Ajustez les références aux propriétés d’événement renommées et déplacées, comme indiqué dans la section Modifications majeures.
  2. Au lieu de composer et de retourner un objet décrivant les effets secondaires souhaités, mettez à jour le code personnalisé pour appeler la méthode api pertinente, comme indiqué dans la section Exécution d’effets secondaires.
  3. Pour les Actions qui doivent gérer les callbacks de redirection, utilisez la nouvelle fonction dédiée exposée. Si vous utilisiez du code qui reposait sur event.protocol === 'redirect-callback', consultez la page Redirection avec Actions.

​
Changements non rétrocompatibles

​
Paramètres de requête et de corps

L’accès direct aux paramètres de requête et de corps est disponible à l’aide des objets event.request.query et event.request.body. Ceux-ci sont exposés que l’autorisation ait été initiée via une requête GET ou POST. De nombreux paramètres de requête ou de corps spécifiques au protocole envoyés dans le cadre d’une requête d’autorisation sont maintenant également disponibles en tant que valeurs de premier niveau sur l’objet event.transaction. Nous recommandons d’utiliser event.transaction plutôt que event.request.query et event.request.body, à moins que votre cas d’utilisation ne soit pas pris en charge. Une correspondance complète de ces changements se trouve ci-dessous :
Propriété pré-GAPropriété GA
event.actor.ipevent.request.ip
event.actor.hostnameevent.request.hostname
event.actor.geoIpevent.request.geoip
event.actor.languageevent.request.language
event.actor.methodevent.request.method
event.actor.userAgentevent.request.user_agent
event.actor.bodyevent.request.body
event.actor.queryevent.request.query
event.actor.query.audienceevent.resource_server.identifier
event.actor.query.scopeevent.transaction.requested_scopes
event.actor.query.acr_valuesevent.transaction.acr_values
event.actor.query.ui_localesevent.transaction.ui_locales
event.protocolevent.transaction.protocol
context.secretsevent.secrets

​
Propriétés du profil utilisateur

En général, les propriétés de l’objet event.user sont passées du camel case au snake case afin de correspondre à la structure du profil utilisateur Auth0. Par exemple, event.user.appMetadata a été modifiée en event.user.app_metadata.

​
Gestion des effets secondaires

Dans la version pré-GA du déclencheur post-login, les effets secondaires étaient exécutés en renvoyant un objet à partir d’une Action. Dans Actions GA, un objet api est fourni pour encapsuler ces modifications et offrir de meilleures suggestions de types et une documentation intégrée directement dans l’éditeur.

​
Mettre à jour la propriété user_metadata de l’utilisateur

Déclencheur pré-GA : 
async function myFunction(event, context) {
  return {
    user: {
      userMetadata: {
        myParam: "foo"
      }
    }
  };
}
Déclencheur GA : 
async function onExecutePostLogin(event, api) {
  api.user.setUserMetadata('myParam', 'foo');
}
Vous ne devriez pas utiliser cette méthode dans les callbacks, car son invocation ne met pas immédiatement à jour les métadonnées. En revanche, vous pouvez appeler cette méthode plusieurs fois dans différentes Actions au sein du même flux (les métadonnées définies dans une Action sont appliquées à l’objet transitoire et sont donc disponibles dans les Actions suivantes), et le moteur regroupera les modifications et mettra à jour les métadonnées en une seule fois avant la fin du flux.

​
Mettre à jour app_metadata de l’utilisateur

Déclencheur pré-GA : 
async function myFunction(event, context) {
  return {
    user: {
      appMetadata: {
        myParam: "foo"
      }
    }
  };
}
Déclencheur GA : 
async function onExecutePostLogin(event, api) {
  api.user.setAppMetadata('myParam', 'foo');
}
Vous ne devriez pas utiliser cette méthode dans les callbacks, car l’invoquer ne mettra pas immédiatement à jour les métadonnées. Au lieu de cela, vous pouvez appeler cette méthode plusieurs fois dans différentes Actions au sein du même flux (les métadonnées définies dans une Action sont appliquées à l’objet transitoire et sont donc disponibles dans les Actions suivantes), et le moteur regroupera les modifications et mettra à jour toutes les métadonnées en une seule fois avant la fin du flux.

​
Refuser une tentative de connexion

Déclencheur pré-GA : 
async function myFunction(event, context) {
  throw new Error("Accès refusé.");
}
Déclencheur GA : 
async function onExecutePostLogin(event, api) {
  api.access.deny("Accès refusé.");
}
Générer une erreur refusera également une connexion, mais appeler api.access.deny est l’approche recommandée.

​
Ajouter des revendications personnalisées au jeton d’accès

Déclencheur avant la GA : 
async function myFunc(event, context) {
  return {
    accessToken: {
      customClaims: {
        'https://example.com/custom/claim': 'Custom claim value',
      }
    }
  };
}
Déclencheur GA : 
async function myFunc(event, api) {
  api.accessToken.setCustomClaim('https://example.com/custom/claim', 'Custom claim value');
}

​
Ajouter des déclarations personnalisées au jeton ID

Déclencheur avant la disponibilité générale (GA) : 
async function myFunc(event, context) {
  return {
    idToken: {
      customClaims: {
        'https://example.com/custom/claim': 'Valeur de revendication personnalisée',
      }
    }
  };
}
Déclencheur GA : 
async function myFunc(event, api) {
  api.idToken.setCustomClaim('https://example.com/custom/claim', 'Custom claim value');
}

​
Activer dynamiquement l’authentification multifacteur

Déclencheur pré‑GA : 
async function myFunction(event, context) {
  return {
    command: {
      type: "multifactor",
      provider: "any"
    }
  };
}
Déclencheur GA : 
async function onExecutePostLogin(event, api) {
  api.multifactor.enable("duo");
}

​
Rediriger l’utilisateur

Déclencheur avant la disponibilité générale : 
async function myFunction(event, context) {
  return {
    command: {
      type: "redirect",
      url: "https://my-app.example.com"
    }
  };
}
Déclencheur GA : 
async function onExecutePostLogin(event, api) {
  api.redirect.sendUserTo("https://my-app.example.com");
}
Pour veiller à ce que les paramètres soient envoyés de façon sécuritaire et pour éviter les attaques par rejeu, la transmission de données par redirection a considérablement changé dans la version GA d’Actions. Pour en savoir plus, consultez Redirection avec Actions.

​
Manipuler les scopes

Même si nous avons testé la possibilité de permettre la manipulation directe des scopes des jetons d’ID et des pendant la version bêta des Actions, nous ne prenons pas en charge cette fonctionnalité dans la version GA des Actions.