Migrer de Node.js 8 vers Node.js 12

Décrit les fonctionnalités d’Auth0 concernées par la migration de Node.js v8 vers Node.js v12 et fournit des recommandations concernant cette migration.

Depuis le 31 décembre 2019, Node.js v8 n’est plus pris en charge à long terme (LTS), ce qui signifie que l’équipe de développement de Node.js ne rétroporte plus les correctifs de sécurité critiques pour cette version. Cela pourrait exposer votre code d’extensibilité à des failles de sécurité. Par conséquent, Auth0 est passé de Node 8 à Node 12.

​

Fonctionnalités concernées

Les fonctionnalités Auth0 suivantes utilisent Node 8 :

• Rules
• Hooks
• Connexions de base de données personnalisées
• 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 environnement d’exécution Webtask, nous avons effectué plusieurs tests pour déterminer quels modules ne sont pas compatibles avec le passage de Node 8 à 12. La plupart des clients devraient pouvoir passer à Node 12 sans problème.

Cela dit, avant d’effectuer la migration, nous vous recommandons fortement de tester tous vos éléments suivants :

• Rules
• Hooks
• connexions de base de données personnalisées et scripts
• connexions sociales personnalisées
• extensions

Auth0 recommande de commencer par faire passer votre locataire de développement à l’environnement d’exécution Node 12, d’effectuer tous les tests dans votre locataire de développement, puis de migrer votre locataire de production uniquement lorsque vous ne constatez aucun problème dans l’environnement de développement.

​

Activer l’environnement d’exécution Node 12

Cette migration peut entraîner d’autres changements de comportement. Nous avons donc ajouté une option de migration qui vous permet de contrôler la migration de votre environnement vers le nouvel environnement d’exécution Webtask avec Node 12.

Auth0 recommande de faire passer d’abord votre locataire de développement à l’environnement d’exécution Node 12, d’effectuer les tests dans ce locataire, puis de migrer votre locataire de production seulement si vous ne constatez aucun problème en développement.

Vous pouvez interroger la Management API pour vos Rules, Hooks, scripts de base de données personnalisés et connexions sociales personnalisées. Cela vous permettra de déplacer plus facilement des éléments de votre locataire de production vers votre locataire de développement à des fins de test.

Lorsque vous utilisez les points de terminaison Connections dans la Management API, les scripts de base de données personnalisés peuvent être récupérés ou mis à jour à l’aide de options.customScripts. De même, vous trouverez les connexions sociales personnalisées dans options.scripts.fetchUserProfile.

1. Activez Node 12 dans votre locataire de développement à l’aide du nouveau panneau Extensibility de la page Advanced Tenant Settings de l’Auth0 Dashboard. Choisissez Node 12 dans la liste déroulante Runtime.
2. Cliquez sur Save.
3. Si vous utilisez les éléments ci-dessous, effectuez les étapes de migration pour chacun d’eux.
4. Testez votre configuration.
5. Une fois que vous êtes certain que rien n’a cessé de fonctionner, suivez les étapes 1 et 2 ci-dessus pour activer Node 12 dans votre locataire de production.

​

Ajouter les nouvelles URL à la liste d’autorisation

L’extension Delegated Administration et l’extension de tableau de bord Single Sign-on (SSO) exigent que les URL utilisées pour accéder aux extensions et aux webtasks personnalisés soient ajoutées à la liste d’autorisation. Lorsque vous effectuez la mise à niveau vers 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 régionale de l’URL 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 effectuez la mise à niveau vers Node 12, l’URL deviendra :

https://{yourTenant}.us12.webtask.io/dummy-extension-url

1. Accédez à Auth0 Dashboard > Applications > Applications > Settings, puis ajoutez l’URL aux champs Allowed Callback URLs et Allowed Logout URLs.
2. Les URL d’exécution changeront également pour les webtasks personnalisés dans votre conteneur Auth0. Vous devez mettre à jour toutes les applications externes qui appellent ces webtasks.

​

Republier la Rule de l’Authorization Extension

Si vous utilisez l’Authorization Extension, elle génère une Rule auth0-authorization-extension. Republiez cette Rule depuis l’Authorization Extension pour mettre à jour automatiquement les URL.

1. Assurez-vous d’avoir effectué la mise à niveau vers la version la plus récente de l’Authorization Extension à partir de l’onglet Installed Extensions. Si le bouton Upgrade est affiché, cliquez dessus pour effectuer la mise à niveau. Si ce bouton n’est pas affiché, vous utilisez déjà la version la plus récente de l’extension.
2. Ouvrez la page de configuration de l’Authorization Extension.
3. Pour mettre à jour l’URL dans la Rule, publiez de nouveau la Rule en cliquant sur le bouton Publish Rule.
4. Vérifiez que tout fonctionne toujours correctement. Si vous voyez une erreur Invalid API Key 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, le tableau suivant présente les URL mises à jour que vous devez configurer après avoir migré vers Node 12. L’URL varie selon votre région.

Région	Allowed Callback URL pour Node 12	Allowed Logout URL pour Node 12
US-1	https://{yourTenant}.us12.webtask.io/auth0-delegated-admin/login	https://{yourTenant}.us12.webtask.io/auth0-delegated-admin
US-3	https://{yourTenant}.us.webtask.run/auth0-delegated-admin/login	https://{yourTenant}.us.webtask.run/auth0-delegated-admin
EU	https://{yourTenant}.eu12.webtask.io/auth0-delegated-admin/login	https://{yourTenant}.eu12.webtask.io/auth0-delegated-admin
AU	https://{yourTenant}.au12.webtask.io/auth0-delegated-admin/login	https://{yourTenant}.au12.webtask.io/auth0-delegated-admin
JP-1	https://{yourTenant}.jp.webtask.run/auth0-delegated-admin/login	https://{yourTenant}.jp.webtask.run/auth0-delegated-admin

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 tableau de bord SSO

Le tableau suivant contient les URL mises à jour que vous devez configurer après avoir migré vers Node 12. L’URL varie selon votre région.

L’URL de connexion pour les administrateurs :

Région	Allowed Callback URL
US-1	https://{yourTenant}.us12.webtask.io/auth0-sso-dashboard/admins/login
US-3	https://{yourTenant}.us.webtask.run/auth0-sso-dashboard/admins/login
Europe	https://{yourTenant}.eu12.webtask.io/auth0-sso-dashboard/admins/login
Australie	https://{yourTenant}.au12.webtask.io/auth0-sso-dashboard/admins/login
Japon	https://{yourTenant}.jp.webtask.run/auth0-sso-dashboard/admins/login

L’URL de connexion pour les utilisateurs :

Région	Allowed Callback URL
US-1	https://{yourTenant}.us12.webtask.io/auth0-sso-dashboard/login
US-3	https://{yourTenant}.us.webtask.run/auth0-sso-dashboard/login
Europe	https://{yourTenant}.eu12.webtask.io/auth0-sso-dashboard/login
Australie	https://{yourTenant}.au12.webtask.io/auth0-sso-dashboard/login
Japon	https://{yourTenant}.jp.webtask.run/auth0-sso-dashboard/login

​

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 de l’environnement d’exécution et n’est pas mis à jour automatiquement.

Pour le mettre à jour, vous devez enregistrer les paramètres de l’extension (sans apporter de modifications). Pour ce faire, après avoir fait passer l’environnement d’exécution à Node 12, ouvrez les paramètres de l’extension dans le tableau de bord des extensions (icône d’engrenage), puis cliquez sur Save. La galerie des extensions mettra ensuite à jour le secret PUBLIC_WT_URL en fonction de l’environnement d’exécution sélectionné.

Si vous ne mettez pas à jour le secret masqué PUBLIC_WT_URL, vous obtiendrez l’erreur suivante :

​

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 chargés explicitement), sachez que certaines versions ont été mises à jour pour fonctionner avec Node 12. Le tableau suivant résume ces changements. Ces nouvelles versions devraient rester rétrocompatibles avec les versions précédentes.

Nom du module	Ancienne version	Nouvelle version
couchbase	~2.5.1	2.6.10
bcrypt	1.0.3	3.0.8

Si vous avez verrouillé manuellement des modules à une version donnée, vous devrez peut-être aussi les mettre à jour manuellement pour que votre code s’exécute 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’);