Migrer de Node 12 et 16 vers Node 18

Décrit les éléments d’Auth0 Actions touchés par la migration de Node.js v12 et v16 vers Node.js v18.

Le soutien à long terme (LTS) de Node.js 12 et 16 a pris fin en 2023, ce qui signifie que l’équipe de développement de Node.js ne rétroporte plus les correctifs de sécurité critiques vers ces versions. L’exécution de vos runtimes sur Node 12 ou 16 pourrait exposer votre code d’extensibilité à des vulnérabilités de sécurité.

Le runtime d’extensibilité Node 18 est offert de façon générale (GA) dans l’ensemble de notre offre d’extensibilité. Cela comprend Actions, Rules, Hooks, Database Scripts et Custom Social Connections. Nous vous encourageons fortement à passer à Node 18 dès que possible afin de suivre les meilleures pratiques en matière de sécurité du code.

​

Considérations générales

​

Migrer les Rules et Hooks vers Actions

Si vous utilisez un runtime d’extensibilité obsolète, nous vous recommandons de profiter de la révision de votre mise en œuvre des Rules et des Hooks pour les migrer vers les Actions (Node 18). Déterminez quels Rules et Hooks vous pouvez migrer vers les Actions en consultant Actions Limitations. Pour en savoir plus sur la migration de vos Rules et Hooks vers les Actions, consultez Migrate to Actions.

​

Intégrations Marketplace

​

Intégrations des connexions sociales

Utilisez la Management API pour obtenir la liste complète des connexions sociales susceptibles d’être touchées par un changement de version du runtime Node. Plus précisément, toutes les connexions sociales potentiellement touchées, qu’elles aient été créées explicitement comme connexion sociale personnalisée ou ajoutées initialement par l’entremise du Marketplace, ont l’attribut strategy dont la valeur est oauth1 ou oauth2.

Vous pouvez ensuite parcourir, par pagination, toutes les connexions sociales personnalisées existantes dans un tenant donné à l’aide de l’endpoint GET connections de la Management API. Par exemple, les options de requête suivantes renvoient les noms et les identifiants d’un maximum de 100 connexions sociales personnalisées :

/api/v2/connections?strategy=oauth1&strategy=oauth2&include_totals=true&fields=name&per_page=100

Le Auth0 Dashboard ne permet pas de mettre à jour les scripts des connexions sociales personnalisées ajoutées via Marketplace. Si un changement au script est nécessaire pour assurer la compatibilité avec Node 18, vous devez utiliser la Management API.

​

Tâches de migration

​

Créer de nouvelles Actions personnalisées

Pour créer une nouvelle Action personnalisée avec Node 18 à partir d’Auth0 Dashboard :

1. Accédez à Auth0 Dashboard > Actions > Library.
2. Sélectionnez Create Action > Build from scratch.
3. Dans le champ Runtime*, sélectionnez Node 18 (Recommended).
4. Rédigez vos Actions personnalisées en Node 18, testez-les, puis déployez-les lorsque vous êtes prêt.

​

Mettre à niveau les Actions personnalisées existantes

Vous pouvez mettre à niveau individuellement les Actions personnalisées existantes basées sur Node 12 ou 16 vers Node 18 et rétablir la version précédente en utilisant l’ancien runtime. Pour faire passer les Actions à Node 18, créez et déployez une nouvelle version de l’implémentation existante avec les modifications requises, puis configurez-la pour utiliser Node 18 comme runtime.

​

Choisissez Node 18 pour les autres produits d’extensibilité

Le runtime utilisé pour les autres offres d’extensibilité (hors Actions) est défini globalement dans les paramètres avancés du tenant. La modification de ce paramètre a une incidence sur les fonctionnalités suivantes en même temps :

• rules
• hooks
• scripts de base de données personnalisés
• scripts de connexion sociale personnalisée

Pour modifier le paramètre de runtime d’extensibilité du tenant dans l’Auth0 Dashboard :

1. Accédez à Dashboard > Settings > Advanced.
2. Faites défiler jusqu’à la section Extensibility.
3. Pour Runtime, sélectionnez Node 18.

Comme il s’agit d’un paramètre global qui a une incidence sur plusieurs fonctionnalités d’extensibilité à la fois, nous vous recommandons d’effectuer d’abord cette étape dans votre tenant de développement, de terminer les tests de toutes les fonctionnalités d’extensibilité applicables, puis de passer à votre tenant de production seulement lorsque vous ne constatez aucun problème en développement.

Plus précisément pour les Custom DB scripts, vous pouvez suivre les étapes expliquées sur cette page pour vérifier individuellement un script avec une version précise du runtime avant de modifier la version globale du runtime.

​

Incompatibilités connues

​

Modules npm magiques

Le runtime d’extensibilité Node 12 permet d’utiliser certains modules npm sans les inclure explicitement dans le code d’extensibilité. À partir du runtime Node 16, nous avons retiré la prise en charge de ce type d’utilisation pour les modules suivants :

• _
• async
• Auth0
• azure_storage
• bcrypt
• crypto
• couchbase
• cql
• ip
• jwt
• Knex
• mongo
• mysql
• mysql_pool
• ObjectID
• pbkdf2
• pg
• postgres
• Pubnub
• q
• querystring
• sqlserver
• uuid
• xml2js
• xmldom
• xpath
• xtend

Si vous avez encore du code d’extensibilité qui s’exécute sur Node 12, tenez compte de ce qui précède lorsque vous mettez le code à jour directement vers Node 18. Avant d’utiliser un module, vous devez vous assurer de l’inclure explicitement.

Dans le contexte de Rules, Custom Database Connections et connexions sociales personnalisées, vous devez inclure explicitement une version du module indiquée comme disponible pour Node 18.

Dans Hooks et Actions, vous devez ajouter la version cible voulue comme dépendance explicite avant d’inclure le module.

​

Versions de modules supprimées de Can I Require

Nous avons retiré de Can I Require la prise en charge des versions précisées des modules énumérés ci-dessous pour le runtime Node 18. Cette modification touche le code d’extensibilité associé à Rules, aux scripts de Custom Database Connection et aux scripts de connexion sociale personnalisée.

Le script Fetch User Profile pour les connexions sociales personnalisées suivantes (Indeed, monday.com, Snapchat et Tumblr), offertes dans le Marketplace, utilisait la version 0.22.0 du module axios, qui n’est pas disponible dans Node 18. Si vous utilisez l’une de ces connections, vérifiez et mettez à jour les scripts correspondants au besoin au moyen de la Management API.

Module	Versions
@analytics/google-analytics	0.4.0
@auth0/hapi	13.5.1, 13.6.0
@auth0/rule-utilities	0.1.0
@gitbeaker/node	17.0.1
@incognia/api	1.0.0
@octokit/rest	15.8.2
@sentry/node	5.6.2, 5.15.5, 6.2.0
acorn	1.2.2
airbrake	1.0.2
airgram	3.1.1
ajv	6.10.1
amazon-dax-client	1.2.2
amazon-mws-node	1.0.3
analytics	0.5.1
analytics-node	2.0.1, 3.5.0
applicationinsights	0.15.8, 0.18.0, 1.5.0, 1.8.8
async	1.0.0, 0.9.0, 2.1.2, 2.6.1
auth0	2.4.0, 2.1.0, 2.0.0, 0.8.2, 2.6.0, 2.7.0, 2.8.0, 2.9.1, 2.13.0, 2.17.0, 2.17.1, 2.19.0, 2.23.0, 2.27.0, 2.27.1, 2.30.0, 2.31.0, 2.32.0, 2.34.2, 2.35.0, 2.36.1, 2.36.2, 2.39.0, 3.0.1
auth0-authz-rules-api	4.0.0
auth0-ext-template-renderers	0.4.2
auth0-extension-express-tools	1.0.2, 1.1.5, 1.1.6, 2.0.0
auth0-extension-hapi-tools	1.0.0, 1.1.0, 1.2.0, 1.2.1, 1.2.2, 1.3.0
auth0-extension-tools	1.0.0, 1.2.1, 1.3.1, 1.3.2, 1.4.0
auth0-magic	3.1.0
auth0-oauth2-express	0.0.1, 0.0.3, 1.1.5
auth0-source-control-extension-tools	3.0.10, 3.0.9, 3.1.4, 3.4.0, 3.5.1, 4.0.3, 4.0.5, 4.0.6, 4.0.7, 4.1.1, 4.1.2, 4.1.3, 4.1.5, 4.1.7, 4.1.9
aws-sdk	2.2.30, 2.1.31, 2.1.13, 2.4.13, 2.5.3, 2.197.0, 2.291.0, 2.458.0, 2.593.0
axios	0.15.2, 0.18.0, 0.19.2, 0.21.1, 0.21.3, 0.22.0, 0.27.2
azure	0.10.6
azure-storage	0.4.4, 0.4.1, 0.9.0
babel	5.4.7, 5.1.9
bcrypt	4.0.0
bluebird	2.9.26, 3.4.6
body-parser	1.12.4
boom	2.7.2
botbuilder	0.9.0
bson	0.3.2, 4.4.0
cookie-parser	1.3.5
datadog-metrics	0.8.2, 0.9.0, 0.9.2, 0.9.3
disposable-email-domains	1.0.14, 1.0.15, 1.0.56
dockerode	2.1.4, 2.0.3
dotenv	0.4.0, 2.0.0
easy-pbkdf2	0.0.2
ejs	2.3.1
engine.io-client	1.5.1
express	4.12.4, 4.14.0, 4.16.3
express-jwt	3.1.0, 5.1.0
faunadb	2.11.1, 4.1.1
filter-object	2.1.0
firebase	7.12.0
firebase-admin	4.0.4, 5.0.0, 6.0.0, 8.0.0, 8.12.1
form-data	0.2.0
getstream	3.4.1
gitlab	1.7.0
google-auth-library	1.0.0
google-libphonenumber	2.0.7, 3.2.8, 3.2.10
googleapis	2.1.6, 34.0.0
got	3.2.0, 9.2.1, 10.7.0, 11.3.0, 11.5.2
hapi	13.5.0
hapi-auth-jwt2	7.0.1
hapi-swagger	7.4.0
hoek	2.14.0
http-proxy	1.11.1
ibm_db	2.6.4
ip	0.3.2, 0.0.1
ipaddr.js	1.0.1
joi	6.10.1
jose	3.19.0
jsforce	1.6.0
jsonwebtoken	5.7.0, 5.0.1, 5.0.0, 7.1.9, 8.5.0
jwks-rsa	1.0.0, 1.1.1, 1.6.0
ldapjs	1.0.0
lodash	3.10.1, 3.9.3, 2.4.1, 4.8.2, 4.17.10, 4.17.19
lru-cache	2.6.4
mixpanel	0.4.0
mkdirp	0.5.1
moment	2.10.3, 2.11.2
mongodb	2.0.48, 2.0.33, 2.0.27, 2.2.11, 3.1.4, 4.1.0, 3.6.10, 3.5.11
mongoose	4.1.6
morgan	1.5.3
mysql	2.7.0, 2.6.2, 2.0.0-alpha8, 2.15.0
mysql2	1.5.3
nano	6.2.0
neo4j-driver	1.7.1
node-fetch	2.6.0
node-jose	0.9.2
node-rdkafka	2.10.1
nodemailer	2.5.0
nsp	2.4.0
oauth	0.9.12
passport-wsfed-saml2	2.11.4
pg	4.5.7, 4.3.0, 4.1.1, 6.1.2, 7.17.1
postmark	1.3.1
q	1.0.1
qs	3.1.0
ramda	0.18.0, 0.23.0
range_check	0.0.1
raw-body	2.1.0
react	15.3.2
redis	0.12.1
request	2.56.0, 2.55.0, 2.27.0, 2.67.0, 2.73.0, 2.75.0, 2.81.0, 2.83.0, 2.88.0
rethinkdb	2.1.1, 2.0.0-1, 2.0.0
rollbar	0.6.2, 2.12.2
semver	4.3.4
sendgrid	1.8.0, 3.0.7
sequelize	3.1.1
soap	0.23.0
socket.io	1.3.5
socket.io-client	1.3.5
splunk-bunyan-logger	0.9.1
ssh2	0.4.13
stamplay	1.0.6, 1.0.5, 1.0.3
stripe	3.3.4, 4.14.0, 4.24.0, 7.1.0, 7.4.0, 8.52.0
sumo-logger	1.5.5
superagent	1.2.0, 3.8.3, 4.1.0
tedious	6.6.2, 1.11.0, 0.1.4, 8.3.1, 9.2.1
tough-cookie	1.2.0
twilio	2.2.1, 3.6.0, 3.57.0
twit	1.1.20
uuid	2.0.3, 2.0.1, 3.1.0, 3.3.2, 7.0.3, 8.0.0
vso-node-api	3.1.1
watson-developer-cloud	2.0.1
winston	1.0.0, 0.8.1, 3.1.0
xml2js	0.4.8, 0.2.8
xmlbuilder	2.6.4
xmldom	0.1.19, 0.1.13
xpath	0.0.5
xtend	1.0.3

​

Renégociation sécurisée requise par défaut pour les connexions TLS

Node.js 18 exige par défaut la renégociation sécurisée (RFC 5746) pour les connexions TLS, puisque cette exigence a été introduite dans la dépendance OpenSSL sous-jacente.

Si votre code d’extensibilité effectue des appels réseau vers des services externes, les serveurs cibles doivent prendre en charge la renégociation sécurisée; sinon, les requêtes échoueront et vous recevrez une erreur semblable à :

Error: write EPROTO C0BAF076:error:0A000152:SSL routines:final_renegotiate:unsafe legacy renegotiation disabled:../deps/openssl/openssl/ssl/statem/extensions.c:922:

Compte tenu de ce changement touchant la sécurité, nous vous recommandons de vérifier que tous les serveurs visés ont été mis à jour pour prendre en charge la renégociation sécurisée. Si les serveurs en question sont des serveurs tiers qui ne sont pas sous votre contrôle, vous pouvez évaluer la possibilité d’opter explicitement pour le comportement précédent.

Par exemple, pour la bibliothèque axios, l’extrait de code suivant montre comment opter explicitement pour l’ancien comportement :

const axios = require('axios');
const https = require('https');
const crypto = require('crypto');

axios.get(
  'https://[LEGACY_SERVER]', 
  {
    httpsAgent: new https.Agent(
      {
        secureOptions: crypto.constants.SSL_OP_LEGACY_SERVER_CONNECT
      }
    )
  })