Saltar al contenido principal
El soporte a largo plazo (LTS) de Node.js 12 y 16 finalizó en 2023, lo que significa que el equipo de desarrollo de Node.js ya no incorpora retroactivamente correcciones de seguridad críticas a estas versiones. Usar los runtimes de Node 12 o 16 podría exponer su código de extensibilidad a vulnerabilidades de seguridad. El runtime de extensibilidad de Node 18 está disponible de forma general (GA) en toda nuestra oferta de extensibilidad. Esto incluye Actions, Rules, Hooks, scripts de base de datos y conexiones sociales personalizadas. Recomendamos encarecidamente actualizar a Node 18 lo antes posible para seguir las mejores prácticas de seguridad del código.

Consideraciones generales

Migrar Rules y Hooks a Actions

Si usa un runtime de extensibilidad obsoleto, le recomendamos aprovechar la revisión de su implementación de Rules y Hooks para migrarlos a Actions (Node 18). Para determinar cuáles de sus Rules y Hooks puede migrar a Actions, consulte Limitaciones de Actions. Para obtener más información sobre cómo migrar sus Rules y Hooks a Actions, consulte Migrar a Actions.

Integraciones del Marketplace

Integraciones de conexiones sociales

Use la Management API para identificar una lista completa de conexiones sociales que podrían verse afectadas por un cambio en la versión del runtime de Node. En particular, todas las conexiones sociales potencialmente afectadas, ya sea que se hayan creado explícitamente como una conexión social personalizada o que se hayan agregado inicialmente a través del Marketplace, tienen el atributo strategy con un valor de oauth1 o oauth2. A continuación, puede recorrer con paginación todas las conexiones sociales personalizadas existentes en un inquilino determinado mediante el endpoint GET connections de la . Por ejemplo, las siguientes opciones de consulta devuelven los nombres y los identificadores de hasta 100 conexiones sociales personalizadas:
/api/v2/connections?strategy=oauth1&strategy=oauth2&include_totals=true&fields=name&per_page=100
El no permite actualizar los scripts de las conexiones sociales personalizadas agregadas a través de Marketplace. Si es necesario modificar un script para que sea compatible con Node 18, debe usar la Management API.

Tareas de migración

Crear nuevas Actions personalizadas

Para crear una nueva Action personalizada con Node 18 desde el Auth0 Dashboard:
  1. Vaya a Auth0 Dashboard > Actions > Library.
  2. Seleccione Create Action > Build from scratch.
  3. En el campo Runtime*, seleccione Node 18 (Recommended).
  4. Escriba sus Actions personalizadas en Node 18, pruébelas y despliéguelas cuando estén listas.

Actualice las Actions personalizadas existentes

Puede actualizar individualmente las Actions personalizadas existentes creadas con Node 12 o 16 a Node 18 y volver a la versión anterior con el runtime anterior. Actualice las Actions a Node 18 creando e implementando una nueva versión de la implementación existente con los cambios necesarios y configurándola para usar Node 18 como runtime.

Seleccione Node 18 para otros productos de extensibilidad

El runtime que se usa para las demás opciones de extensibilidad (que no son Actions) se define globalmente en la configuración avanzada del inquilino. Cambiar esta configuración afecta a la siguiente funcionalidad al mismo tiempo:
  • rules
  • hooks
  • scripts de base de datos personalizada
  • scripts de conexiones sociales personalizadas
Para cambiar la configuración del runtime de extensibilidad del inquilino en el Auth0 Dashboard:
  1. Vaya a Dashboard > Settings > Advanced.
  2. Desplácese hasta la sección Extensibility.
  3. En Runtime, seleccione Node 18.
Dado que se trata de una configuración global que afecta a varias funcionalidades de extensibilidad de forma simultánea, le recomendamos realizar primero este paso en su inquilino de desarrollo, completar las pruebas de todas las funcionalidades de extensibilidad aplicables y pasar a su inquilino de producción solo cuando no detecte ningún problema en desarrollo. En el caso concreto de los scripts de Custom DB, puede seguir los pasos que se explican en esta página para verificar individualmente un script con una versión específica del runtime antes de cambiar la versión global del runtime.

Cambios incompatibles con versiones anteriores ya conocidos

Módulos mágicos de npm

El runtime de extensibilidad de Node 12 permite usar determinados módulos de npm sin tener que requerirlos explícitamente en el código de extensibilidad. A partir del runtime de Node 16, eliminamos la compatibilidad con este tipo de uso para los siguientes módulos:
  • _
  • async
  • Auth0
  • azure_storage
  • bcrypt
  • crypto
  • couchbase
  • cql
  • ip
  • Knex
  • mongo
  • mysql
  • mysql_pool
  • ObjectID
  • pbkdf2
  • pg
  • postgres
  • Pubnub
  • q
  • querystring
  • sqlserver
  • uuid
  • xml2js
  • xmldom
  • xpath
  • xtend
Si todavía tiene extensibilidad ejecutándose en Node 12, tenga en cuenta lo anterior al actualizar el código directamente a Node 18. Antes de usar un módulo, debe asegurarse de requerirlo explícitamente. En el contexto de Rules, las conexiones de base de datos personalizadas y las conexiones sociales personalizadas, debe requerir explícitamente una versión del módulo que aparezca como disponible para Node 18. En Hooks y Actions, debe agregar la versión de destino prevista como una dependencia explícita antes de requerir el módulo.

Versiones de módulos eliminadas en Can I Require

Hemos eliminado de Can I Require la compatibilidad con las versiones especificadas de los módulos que se enumeran a continuación para el runtime de Node 18. Este cambio afecta al código de extensibilidad asociado con Rules, los scripts de base de datos personalizada y los scripts de conexiones sociales personalizadas.
El script de obtención del perfil de usuario para las siguientes conexiones sociales personalizadas (Indeed, monday.com, Snapchat y Tumblr), disponibles a través de Marketplace, usaba la versión 0.22.0 del módulo axios, que no está disponible en Node 18. Si usa una de estas conexiones, revise y actualice sus scripts según sea necesario mediante la Management API.
MóduloVersiones
@analytics/google-analytics0.4.0
@auth0/hapi13.5.1, 13.6.0
@auth0/rule-utilities0.1.0
@gitbeaker/node17.0.1
@incognia/api1.0.0
@octokit/rest15.8.2
@sentry/node5.6.2, 5.15.5, 6.2.0
acorn1.2.2
airbrake1.0.2
airgram3.1.1
ajv6.10.1
amazon-dax-client1.2.2
amazon-mws-node1.0.3
analytics0.5.1
analytics-node2.0.1, 3.5.0
applicationinsights0.15.8, 0.18.0, 1.5.0, 1.8.8
async1.0.0, 0.9.0, 2.1.2, 2.6.1
auth02.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-api4.0.0
auth0-ext-template-renderers0.4.2
auth0-extension-express-tools1.0.2, 1.1.5, 1.1.6, 2.0.0
auth0-extension-hapi-tools1.0.0, 1.1.0, 1.2.0, 1.2.1, 1.2.2, 1.3.0
auth0-extension-tools1.0.0, 1.2.1, 1.3.1, 1.3.2, 1.4.0
auth0-magic3.1.0
auth0-oauth2-express0.0.1, 0.0.3, 1.1.5
auth0-source-control-extension-tools3.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-sdk2.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
axios0.15.2, 0.18.0, 0.19.2, 0.21.1, 0.21.3, 0.22.0, 0.27.2
azure0.10.6
azure-storage0.4.4, 0.4.1, 0.9.0
babel5.4.7, 5.1.9
bcrypt4.0.0
bluebird2.9.26, 3.4.6
body-parser1.12.4
boom2.7.2
botbuilder0.9.0
bson0.3.2, 4.4.0
cookie-parser1.3.5
datadog-metrics0.8.2, 0.9.0, 0.9.2, 0.9.3
disposable-email-domains1.0.14, 1.0.15, 1.0.56
dockerode2.1.4, 2.0.3
dotenv0.4.0, 2.0.0
easy-pbkdf20.0.2
ejs2.3.1
engine.io-client1.5.1
express4.12.4, 4.14.0, 4.16.3
express-jwt3.1.0, 5.1.0
faunadb2.11.1, 4.1.1
filter-object2.1.0
firebase7.12.0
firebase-admin4.0.4, 5.0.0, 6.0.0, 8.0.0, 8.12.1
form-data0.2.0
getstream3.4.1
gitlab1.7.0
google-auth-library1.0.0
google-libphonenumber2.0.7, 3.2.8, 3.2.10
googleapis2.1.6, 34.0.0
got3.2.0, 9.2.1, 10.7.0, 11.3.0, 11.5.2
hapi13.5.0
hapi-auth-jwt27.0.1
hapi-swagger7.4.0
hoek2.14.0
http-proxy1.11.1
ibm_db2.6.4
ip0.3.2, 0.0.1
ipaddr.js1.0.1
joi6.10.1
jose3.19.0
jsforce1.6.0
jsonwebtoken5.7.0, 5.0.1, 5.0.0, 7.1.9, 8.5.0
jwks-rsa1.0.0, 1.1.1, 1.6.0
ldapjs1.0.0
lodash3.10.1, 3.9.3, 2.4.1, 4.8.2, 4.17.10, 4.17.19
lru-cache2.6.4
mixpanel0.4.0
mkdirp0.5.1
moment2.10.3, 2.11.2
mongodb2.0.48, 2.0.33, 2.0.27, 2.2.11, 3.1.4, 4.1.0, 3.6.10, 3.5.11
mongoose4.1.6
morgan1.5.3
mysql2.7.0, 2.6.2, 2.0.0-alpha8, 2.15.0
mysql21.5.3
nano6.2.0
neo4j-driver1.7.1
node-fetch2.6.0
node-jose0.9.2
node-rdkafka2.10.1
nodemailer2.5.0
nsp2.4.0
oauth0.9.12
passport-wsfed-saml22.11.4
pg4.5.7, 4.3.0, 4.1.1, 6.1.2, 7.17.1
postmark1.3.1
q1.0.1
qs3.1.0
ramda0.18.0, 0.23.0
range_check0.0.1
raw-body2.1.0
react15.3.2
redis0.12.1
request2.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
rethinkdb2.1.1, 2.0.0-1, 2.0.0
rollbar0.6.2, 2.12.2
semver4.3.4
sendgrid1.8.0, 3.0.7
sequelize3.1.1
soap0.23.0
socket.io1.3.5
socket.io-client1.3.5
splunk-bunyan-logger0.9.1
ssh20.4.13
stamplay1.0.6, 1.0.5, 1.0.3
stripe3.3.4, 4.14.0, 4.24.0, 7.1.0, 7.4.0, 8.52.0
sumo-logger1.5.5
superagent1.2.0, 3.8.3, 4.1.0
tedious6.6.2, 1.11.0, 0.1.4, 8.3.1, 9.2.1
tough-cookie1.2.0
twilio2.2.1, 3.6.0, 3.57.0
twit1.1.20
uuid2.0.3, 2.0.1, 3.1.0, 3.3.2, 7.0.3, 8.0.0
vso-node-api3.1.1
watson-developer-cloud2.0.1
winston1.0.0, 0.8.1, 3.1.0
xml2js0.4.8, 0.2.8
xmlbuilder2.6.4
xmldom0.1.19, 0.1.13
xpath0.0.5
xtend1.0.3

Se requiere renegociación segura de forma predeterminada para las conexiones TLS

De forma predeterminada, Node.js 18 requiere renegociación segura (RFC 5746) para las conexiones TLS, como consecuencia de que este requisito se introdujo en la dependencia subyacente de OpenSSL. Si su código de extensibilidad realiza llamadas de red externas, los servidores de destino deben admitir la renegociación segura; de lo contrario, las solicitudes fallarán y recibirá un error similar a:
Error: write EPROTO C0BAF076:error:0A000152:SSL routines:final_renegotiate:unsafe legacy renegotiation disabled:../deps/openssl/openssl/ssl/statem/extensions.c:922:
Dado este cambio relacionado con la seguridad, le recomendamos que se asegure de que todos los servidores de destino estén actualizados para admitir la renegociación segura. Si los servidores en cuestión son de terceros y no están bajo su control, puede evaluar la posibilidad de optar por el comportamiento anterior. Por ejemplo, en la biblioteca axios, el siguiente fragmento de código muestra cómo optar por el comportamiento legado:
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
      }
    )
  })