Migrer de Node.js 8 à Node.js 12

Depuis le 31 décembre 2019, Node.js v8 ne comprend plus le support à 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 vers cette version. Cela pourrait potentiellement exposer votre code d’extensibilité à des vulnérabilités de sécurité. Par conséquent, Auth0 a migré de Node 8 à Node 12.

Les fonctions Auth0 suivantes utilisent Node 8 :

• Règles

• Hooks

• Connexions à des bases de données personnalisées

• Connexions sociales personnalisées

• Extensions

Si vous n’utilisez aucune des fonctions d’extension mentionnées ci-dessus, vous n’êtes pas concerné par cette migration.

Dans le cadre de l’introduction de Node 12 dans notre moteur d’exécution Webtask, nous avons effectué un certain nombre de tests pour déterminer quels modules ne sont pas compatibles entre Node 8 et 12. La plupart des clients devraient pouvoir passer à Node 12 sans problème.

Cela dit, avant d’effectuer une migration, il est fortement recommandé de tester vos :

• Règles

• Hooks

• Connexions et scripts de base de données personnalisés

• Connexions sociales personnalisées

• Extensions

Auth0 vous recommande d’abord de faire passer votre locataire de développement à l’exécution de Node 12, de terminer les tests dans votre locataire de développement et de ne migrer votre locataire de production que lorsque vous ne rencontrez plus de problèmes dans le développement.

Il peut y avoir d’autres changements de comportement suite à cette migration; c’est pourquoi nous avons fourni un commutateur de migration qui vous permet de contrôler la migration de votre environnement vers la nouvelle exécution Webtask en utilisant Node 12.

Auth0 vous recommande d’abord de faire passer votre locataire de développement à l’exécution de Node 12, de terminer les tests dans votre locataire de développement et de ne migrer votre locataire de production que lorsque vous ne rencontrez plus de problèmes dans le développement.

Vous pouvez interroger Management API pour vos règles, hooks, scripts de base de données personnalisés et connexions personnalisées via réseaux sociaux. Il vous sera ainsi plus facile de déplacer des éléments de votre locataire de production vers le locataire de développement à des fins de test.

Lorsque vous utilisez les points de terminaison des connexions dans 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 pouvez trouver des connexions sociales personnalisées dans options.scripts.fetchUserProfile.

1. Activez Node 12 sur votre locataire de développement en utilisant le nouveau panneau Extensibilité sur la page Paramètres avancés du locataire de Dashboard. Sélectionnez Node 12 à partir du menu déroulant Exécution.

2. Cliquez sur Enregistrer.

3. Si vous utilisez les éléments énumérés ci-dessous, effectuez les étapes de migration pour chacun d’entre eux.

4. Testez votre configuration.

5. Une fois que vous êtes sûr que rien n’entraîne de bogue, utilisez les étapes 1 et 2 ci-dessus pour activer Node 12 sur votre locataire de production.

L’extension Delegated Administration et l’extension Dashboard à authentification unique (SSO) requièrent la mise en liste d’autorisation des URL utilisées pour accéder aux extensions et aux tâches web personnalisées. Lors de la mise à niveau vers Node 12, les URL utilisées pour accéder aux extensions et aux tâches Web personnalisées seront modifiées. Il s’agit d’un changement majeur pour ces extensions.

Si vous utilisez l’une de ces extensions, vous devez autoriser les nouvelles URL en tant que Callback URL autorisées et URL de déconnexion autorisées.

La partie région de l’URL passe de 8 à 12. Si vous accédez à une extension en utilisant l’URL :

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

lorsque vous effectuerez une mise à jour vers Node 12, l’URL sera :

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

1. Allez à Dashboard > Applications > Applications > Paramètres, et ajoutez URL aux champs Callback URL autorisées et URL de déconnexion autorisées.

2. Les URL d’exécution seront également modifiées pour les tâches Web personnalisées dans votre conteneur Auth0. Vous devez mettre à jour toutes les applications externes qui appellent ces tâches Web.

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

1. Assurez-vous d’avoir mis à jour la dernière version de l’extension d’autorisation à partir de l’onglet Extensions installées. Si le bouton Mettre à niveau est présent, cliquez pour mettre à niveau. Si le bouton n’est pas présent, vous êtes déjà sur la dernière version de l’extension.

2. Ouvrez la page de configuration Authorization Extension.

3. Pour mettre à jour l’URL dans la règle, publiez à nouveau la règle en cliquant sur le bouton Publier la règle.

4. Testez pour vous assurer que tout fonctionne toujours. Si une erreur de clé API invalide apparaît après la mise à jour, cliquez sur le bouton Effectuer une rotation pour générer une nouvelle clé API.

Si vous utilisez l’Administration Extension déléguée, la matrice suivante contient les URL mises à jour que vous devez configurer après avoir migré vers Node 12. L’URL varie en fonction de votre emplacement.

For example, if you are located in the USA and you use the Delegated Administration, you should update the following fields in your application’s settings:

• URL de rappel autorisées: https://{yourTenant}.us12.webtask.io/auth0-delegated-admin/login

• URL de déconnexions permises: https://{yourTenant}.us12.webtask.io/auth0-delegated-admin

La matrice suivante contient les URL mises à jour que vous devez configurer après avoir migré vers le Node 12. L’URL varie en fonction de votre emplacement.

URL de connexion pour les administrateurs :

URL de connexion pour les utilisateurs :

La plupart des extensions utilisent le secret caché PUBLIC_WT_URL pour l’autorisation. Ce secret dépend de la version de l’exécution et n’est pas automatiquement mis à jour.

To update it, you need to save the extension’s settings (no changes are necessary). To do so, after switching the runtime to Node 12, you need to open the extension’s settings in the extensions dashboard (gear icon), and click Save. After that, the extensions gallery will update the PUBLIC_WT_URL secret based on the selected runtime.

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

Si vous utilisez les modules intégrés suivants (c’est-à-dire les modules que vous n’avez pas explicitement requis), sachez 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 épinglé manuellement des modules, vous devrez peut-être les mettre à jour manuellement pour que votre code fonctionne avec Node 12.

Par exemple, vous devrez modifier :

var bcrypt = require(‘bcrypt@1.0.3’);

à

var bcrypt = require(‘bcrypt’);

ou, si le module doit être fixé à une version spécifique :

var bcrypt = require(‘bcrypt@3.0.8’);