Migrar de Node.js 8 a Node.js 12

Describe las funcionalidades de Auth0 afectadas por la migración de Node.js v8 a Node.js v12 y ofrece recomendaciones para dicha migración.

A partir del 31 de diciembre de 2019, Node.js v8 dejó de recibir soporte a largo plazo (LTS), lo que significa que el equipo de desarrollo de Node.js ya no retroporta correcciones de seguridad críticas a esta versión. Esto podría exponer su código de extensibilidad a vulnerabilidades de seguridad. Por lo tanto, Auth0 migró de Node.js 8 a Node.js 12.

​

Características afectadas

Las siguientes características de Auth0 usan Node 8:

• Rules
• Hooks
• conexiones de base de datos personalizadas
• conexiones sociales personalizadas
• Extensiones

Si no usa ninguna de las funciones de extensibilidad mencionadas anteriormente, esta migración no le afecta.

​

Tareas

Como parte del proceso de introducción de Node 12 en nuestro runtime de Webtask, realizamos una serie de pruebas para determinar qué módulos no son compatibles con Node 12 al pasar de Node 8. La mayoría de los clientes deberían poder actualizar a Node 12 sin problemas.

Dicho esto, antes de migrar, le recomendamos encarecidamente que pruebe todos sus:

• Rules
• Hooks
• conexiones y scripts de base de datos personalizadas
• conexiones sociales personalizadas
• extensiones

Auth0 recomienda que primero cambie su inquilino de desarrollo al runtime de Node 12, complete las pruebas en su inquilino de desarrollo y migre su inquilino de producción solo cuando no observe ningún problema en desarrollo.

​

Habilitar el runtime de Node 12

Como resultado de esta migración, puede haber cambios adicionales en el comportamiento, por lo que hemos proporcionado una opción de migración que le permite controlar la migración de su entorno al nuevo runtime de Webtask con Node 12.

Auth0 recomienda que primero cambie su inquilino de desarrollo al runtime de Node 12, complete las pruebas en su inquilino de desarrollo y migre su inquilino de producción solo cuando confirme que no hay problemas en desarrollo.

Puede consultar la Management API para ver sus Rules, Hooks, scripts de base de datos personalizada y conexiones sociales personalizadas. Esto le facilitará mover elementos de su inquilino de producción al inquilino de desarrollo con fines de prueba.

Al usar los endpoints de Connections en la Management API, los scripts de base de datos personalizada se pueden recuperar o actualizar mediante options.customScripts. De forma similar, puede encontrar las conexiones sociales personalizadas en options.scripts.fetchUserProfile.

1. Habilite Node 12 en su inquilino de desarrollo mediante el nuevo panel Extensibility en la página Configuración avanzada del Tenant del Dashboard. Elija Node 12 en el menú desplegable Runtime.
2. Haga clic en Save.
3. Si usa los elementos que se indican a continuación, complete los pasos de migración para cada uno.
4. Pruebe su configuración.
5. Cuando esté seguro de que nada se haya roto, use los pasos 1 y 2 anteriores para habilitar Node 12 en su inquilino de producción.

​

Añada nuevas URL a la lista de permitidas

La extensión Delegated Administration y la extensión del Dashboard de inicio de sesión único (SSO) requieren añadir a la lista de permitidas las URL que se usan para acceder a las extensiones y a los webtasks personalizados. Cuando actualice a Node 12, cambiarán las URL que usa para acceder a las extensiones y a los webtasks personalizados. Este es un cambio incompatible para estas extensiones.

Si usa alguna de estas extensiones, debe añadir las nuevas URL a la lista de permitidas tanto en Allowed Callback URLs como en Allowed Logout URLs.

La parte de la región de la URL cambiará de 8 a 12. Si accede a una extensión con la URL:

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

cuando actualice a Node 12, la URL será:

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

1. Vaya a Dashboard > Applications > Applications > Settings y agregue la URL en los campos Allowed Callback URLs y Allowed Logout URLs.
2. Las URL de ejecución también cambiarán para los webtasks personalizados de su contenedor de Auth0. Debe actualizar cualquier aplicación externa que invoque esos webtasks.

​

Volver a publicar la Rule de Authorization Extension

Si usa Authorization Extension, se genera una Rule auth0-authorization-extension. Vuelva a publicar esta Rule desde Authorization Extension para actualizar automáticamente las URL.

1. Asegúrese de haber actualizado a la versión más reciente de Authorization Extension en la pestaña Installed Extensions. Si aparece el botón Upgrade, haga clic en él para actualizar. Si el botón no aparece, ya está usando la versión más reciente de la extensión.
2. Abra la página de configuración de Authorization Extension.
3. Para actualizar la URL en la Rule, vuelva a publicarla haciendo clic en el botón Publish Rule.
4. Verifique que todo siga funcionando. Si ve un error de Invalid API Key después de la actualización, haga clic en el botón Rotate para generar una nueva clave de API.

​

Configurar las URL de Delegated Administration

Si usa la extensión Delegated Administration, la siguiente tabla contiene las URL actualizadas que debe configurar después de migrar a Node 12. La URL varía según su ubicación.

Ubicación	URL de devolución de llamada permitida para Node 12	URL de cierre de sesión permitida para 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

Por ejemplo, si se encuentra en EE. UU. y usa la extensión Delegated Administration, debe actualizar los siguientes campos en la configuración de su aplicación:

• Allowed Callback URLs: https://{yourTenant}.us12.webtask.io/auth0-delegated-admin/login
• Allowed Logout URLs: https://{yourTenant}.us12.webtask.io/auth0-delegated-admin

​

Configurar las URL del SSO Dashboard

La siguiente tabla contiene las URL actualizadas que debe configurar después de migrar a Node 12. La URL varía según su ubicación.

La URL de inicio de sesión para los Admins:

Ubicación	URL de devolución de llamada permitida
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
Australia	https://{yourTenant}.au12.webtask.io/auth0-sso-dashboard/admins/login
Japan	https://{yourTenant}.jp.webtask.run/auth0-sso-dashboard/admins/login

La URL de inicio de sesión para los usuarios:

Ubicación	URL de devolución de llamada permitida
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
Australia	https://{yourTenant}.au12.webtask.io/auth0-sso-dashboard/login
Japan	https://{yourTenant}.jp.webtask.run/auth0-sso-dashboard/login

​

Actualizar extensiones

La mayoría de las extensiones usan el Secret oculto PUBLIC_WT_URL para la autorización. Este Secret depende de la versión del runtime y no se actualiza automáticamente.

Para actualizarlo, debe guardar la configuración de la extensión (no es necesario realizar ningún cambio). Para ello, después de cambiar el runtime a Node 12, debe abrir la configuración de la extensión en el Dashboard de extensiones (icono de engranaje) y hacer clic en Save. Después, la galería de extensiones actualizará el Secret PUBLIC_WT_URL en función del runtime seleccionado.

Si no actualiza el Secret oculto PUBLIC_WT_URL, recibirá el siguiente error:

​

Actualizar módulos fijados

Si utiliza los siguientes módulos integrados (es decir, módulos que no incluyó explícitamente con require), tenga en cuenta que algunas versiones se actualizaron para funcionar con Node 12. La siguiente tabla resume los cambios. Estas nuevas versiones deberían seguir siendo compatibles con versiones anteriores.

Nombre del módulo	Versión anterior	Versión nueva
couchbase	~2.5.1	2.6.10
bcrypt	1.0.3	3.0.8

Si ha fijado módulos manualmente, es posible que deba actualizarlos también manualmente para que su código se ejecute con Node 12.

Por ejemplo, debe cambiar:

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

por

var bcrypt = require(‘bcrypt’);

o, si el módulo debe fijarse en una versión específica:

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