Skip to main content
Depuis le 31 décembre 2019, Node.js v8 n’est plus couvert par le soutien à long terme (LTS), ce qui signifie que l’équipe de développement de Node.js n’y rétroporte plus les correctifs de sécurité critiques. Cela pourrait exposer votre code d’extensibilité à des vulnérabilités de sécurité. Par conséquent, Auth0 a migré de Node 8 vers Node 12.

​
Fonctionnalités touchées

Les fonctionnalités Auth0 suivantes utilisent Node 8 :
  • Rules
  • Hooks
  • connexions à une base de données personnalisée
  • connexions sociales personnalisées
  • Extensions
Si vous n’utilisez aucune des fonctionnalités d’extensibilité mentionnées ci-dessus, cette migration ne vous concerne pas.

​
Tâches

Dans le cadre de l’introduction de Node 12 dans notre runtime Webtask, nous avons effectué plusieurs tests pour déterminer quels modules ne sont pas compatibles avec les versions ultérieures, de Node 8 à 12. La plupart des clients devraient pouvoir passer à Node 12 sans problème. Cela dit, avant de migrer, nous vous recommandons fortement de tester tous vos éléments suivants :
  • Rules
  • Hooks
  • connexions à la base de données personnalisées et scripts
  • connexions sociales personnalisées
  • Extensions
Auth0 recommande de faire passer d’abord votre tenant de développement au runtime Node 12, d’effectuer tous les tests dans votre tenant de développement, puis de migrer votre tenant de production seulement lorsque vous ne constatez aucun problème en développement.

​
Activer le runtime Node 12

Cette migration peut entraîner d’autres changements de comportement. Nous avons donc ajouté un commutateur de migration qui vous permet de contrôler la migration de votre environnement vers le nouveau runtime Webtask avec Node 12. Auth0 recommande de faire d’abord passer votre tenant de développement au runtime Node 12, d’y effectuer tous les tests nécessaires, puis de migrer votre tenant de production seulement une fois que vous avez confirmé qu’aucun problème ne survient en développement. Vous pouvez interroger la Management API pour vos Rules, Hooks, scripts de base de données personnalisée et connexions sociales personnalisées. Il vous sera ainsi plus facile de déplacer des éléments de votre tenant de production vers votre tenant de développement à des fins de test. Lorsque vous utilisez les endpoints Connections dans la , les scripts de base de données personnalisée peuvent être récupérés ou mis à jour au moyen de options.customScripts. De même, vous trouverez les connexions sociales personnalisées dans options.scripts.fetchUserProfile.
  1. Activez Node 12 sur votre tenant de développement à l’aide du nouveau panneau Extensibilité dans la page Paramètres avancés du tenant du Dashboard. Choisissez Node 12 dans la liste déroulante Runtime.
  2. Cliquez sur Enregistrer.
  3. Si vous utilisez les éléments ci-dessous, suivez les étapes de migration pour chacun d’eux.
  4. Testez votre configuration.
  5. Une fois que vous avez la certitude qu’aucun problème n’est survenu, suivez les étapes 1 et 2 ci-dessus pour activer Node 12 sur votre tenant de production.

​
Ajouter les nouvelles URL à la liste d’autorisation

La Delegated Administration Extension et la Dashboard Extension de (SSO) nécessitent l’ajout à la liste d’autorisation des URL utilisées pour accéder aux extensions et aux Webtasks personnalisés. Lorsque vous passerez à Node 12, les URL utilisées pour accéder aux extensions et aux Webtasks personnalisés changeront. Il s’agit d’un changement incompatible pour ces extensions. Si vous utilisez l’une de ces extensions, vous devez ajouter les nouvelles URL à la liste d’autorisation à la fois dans Allowed Callback URLs et dans Allowed Logout URLs. La partie de l’URL correspondant à la région passera de 8 à 12. Si vous accédez à une extension à l’aide de l’URL : https://{yourTenant}.us8.webtask.io/dummy-extension-url lorsque vous passerez à Node 12, l’URL sera : https://{yourTenant}.us12.webtask.io/dummy-extension-url
  1. Accédez à Dashboard > Applications > Applications > Settings, puis ajoutez l’URL dans les champs Allowed Callback URLs et Allowed Logout URLs.
  2. Les URL d’exécution des Webtasks personnalisés dans votre conteneur Auth0 changeront également. Vous devez mettre à jour toute application externe qui envoie des requêtes à ces Webtasks.

​
Republier la règle Authorization Extension

Si vous utilisez Authorization Extension, elle génère une règle auth0-authorization-extension. Republiez cette règle depuis Authorization Extension pour mettre automatiquement les URL à jour.
  1. Assurez-vous d’avoir mis à niveau Authorization Extension vers sa version la plus récente à partir de l’onglet Installed Extensions. Si le bouton Upgrade est présent, cliquez dessus pour effectuer la mise à niveau. Si ce bouton n’apparaît pas, c’est que vous utilisez déjà la version la plus récente de l’extension.
  2. Ouvrez la page de Configuration d’Authorization Extension.
  3. Pour mettre à jour l’URL dans la règle, republiez-la en cliquant sur le bouton Publish Rule.
  4. Faites un test pour vous assurer que tout fonctionne encore. Si le message d’erreur Invalid API Key s’affiche après la mise à jour, cliquez sur le bouton Rotate pour générer une nouvelle clé API.

​
Configurer les URL de Delegated Administration

Si vous utilisez l’extension Delegated Administration Extension, le tableau ci-dessous présente les URL mises à jour que vous devez configurer après avoir migré vers Node 12. L’URL varie selon votre région. Par exemple, si vous êtes aux États-Unis et que vous utilisez Delegated Administration, vous devez mettre à jour les champs suivants dans les paramètres de votre application :
  • Allowed Callback URLs: https://{yourTenant}.us12.webtask.io/auth0-delegated-admin/login
  • Allowed Logout URLs: https://{yourTenant}.us12.webtask.io/auth0-delegated-admin

​
Configurer les URL du SSO Dashboard

Le tableau suivant contient les URL mises à jour que vous devez configurer après la migration vers Node 12. L’URL varie selon votre emplacement. L’URL de connexion pour les Admins : L’URL de connexion pour les Users :

​
Mettre à jour les extensions

La plupart des extensions utilisent le secret masqué PUBLIC_WT_URL pour l’autorisation. Ce secret dépend de la version du runtime et n’est pas mis à jour automatiquement. Pour le mettre à jour, vous devez enregistrer les Settings de l’extension (aucune modification n’est nécessaire). Pour ce faire, après être passé au runtime Node 12, vous devez ouvrir les Settings de l’extension dans le dashboard Extensions (icône d’engrenage), puis cliquer sur Save. La galerie d’extensions mettra ensuite à jour le secret PUBLIC_WT_URL en fonction du runtime sélectionné. Si vous ne mettez pas à jour le secret masqué PUBLIC_WT_URL, vous recevrez l’erreur suivante :
Erreur de mauvaise configuration ou de panne de service

​
Mettre à jour les modules verrouillés

Si vous utilisez les modules intégrés suivants (c’est-à-dire des modules que vous n’avez pas explicitement chargés), veuillez noter que certaines versions ont été mises à jour pour fonctionner avec Node 12. Le tableau suivant résume les changements. Ces nouvelles versions devraient rester rétrocompatibles avec les versions précédentes. Si vous avez verrouillé manuellement la version de certains modules, vous devrez peut-être aussi les mettre à jour manuellement pour que votre code fonctionne avec Node 12. Par exemple, vous devez remplacer : var bcrypt = require(‘bcrypt@1.0.3’); par var bcrypt = require(‘bcrypt’); ou, si le module doit être verrouillé à une version précise : var bcrypt = require(‘bcrypt@3.0.8’);