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
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
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 deoptions.customScripts. De même, vous trouverez les connexions sociales personnalisées dans options.scripts.fetchUserProfile.
- 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.
- Cliquez sur Enregistrer.
- Si vous utilisez les éléments ci-dessous, suivez les étapes de migration pour chacun d’eux.
- Testez votre configuration.
- 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
- Accédez à Dashboard > Applications > Applications > Settings, puis ajoutez l’URL dans les champs Allowed Callback URLs et Allowed Logout URLs.
- 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ègleauth0-authorization-extension. Republiez cette règle depuis Authorization Extension pour mettre automatiquement les URL à jour.
- 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.
- Ouvrez la page de Configuration d’Authorization Extension.
- Pour mettre à jour l’URL dans la règle, republiez-la en cliquant sur le bouton Publish Rule.
- 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 :
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’);