> ## Documentation Index
> Fetch the complete documentation index at: https://translations.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

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

# Migrer de Node.js 8 vers Node.js 12

Depuis le 31 décembre 2019, [Node.js v8 n’est plus couvert par le soutien à long terme (LTS)](https://github.com/nodejs/Release#release-schedule), 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.

<div id="features-affected">
  ## Fonctionnalités touchées
</div>

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.

<div id="tasks">
  ## Tâches
</div>

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.

<div id="enable-node-12-runtime">
  ### Activer le runtime Node 12
</div>

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](/docs/fr-ca/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 <Tooltip tip="Management API : un produit qui permet aux clients d'effectuer des tâches administratives." cta="Voir le glossaire" href="/docs/fr-ca/glossary?term=Management+API">Management API</Tooltip>, 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](https://manage.auth0.com/#/tenant/advanced) 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.

<div id="allowlist-new-urls">
  ### Ajouter les nouvelles URL à la liste d’autorisation
</div>

La Delegated Administration Extension et la Dashboard Extension de <Tooltip tip="Authentification unique (SSO) : service qui, après la connexion d’un utilisateur à une application, connecte automatiquement cet utilisateur à d’autres applications." cta="Voir le glossaire" href="/docs/fr-ca/glossary?term=Single+Sign-on">Single Sign-on</Tooltip> (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](https://manage.auth0.com/#/applications/\{yourClientId}/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.

<div id="republish-authorization-extension-rule">
  ### Republier la règle Authorization Extension
</div>

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.

<div id="configure-delegated-administration-urls">
  ### Configurer les URL de Delegated Administration
</div>

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.

| Emplacement | 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`

<div id="configure-sso-dashboard-urls">
  ### Configurer les URL du SSO Dashboard
</div>

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 :

| Emplacement | 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 Users :

| Emplacement | 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`  |

<div id="update-extensions">
  ### Mettre à jour les extensions
</div>

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 :

<Frame>
  <img src="https://mintcdn.com/translations/pvjQqAy3EB2TK6NP/docs/images/cdy7uua7fh8z/4mq5ebCa83XNLlbn28pp9s/beb869df9a11d188f30332030655ac9d/node-hidden-secret-error.png?fit=max&auto=format&n=pvjQqAy3EB2TK6NP&q=85&s=e08236377c71df799eb94a413cf6ded2" alt="Erreur de mauvaise configuration ou de panne de service" width="1431" height="1055" data-path="docs/images/cdy7uua7fh8z/4mq5ebCa83XNLlbn28pp9s/beb869df9a11d188f30332030655ac9d/node-hidden-secret-error.png" />
</Frame>

<div id="update-pinned-modules">
  ### Mettre à jour les modules verrouillés
</div>

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.

| 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 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’);`