Lo que los socios ISV deben saber sobre Lightning Web Security ☁️

Lightning Web Security (LWS) habilita algunas de las funciones nuevas más buscadas para Lightning Web Components (LWC), como importaciones de espacios de nombres cruzados, mayor compatibilidad con bibliotecas de JavaScript de terceros y más. Sin embargo, los ISV deben tener en cuenta algunas consideraciones importantes al trabajar con LWS. En esta publicación de blog, brindaremos una breve descripción general de LWS y luego pasaremos a las recomendaciones específicas de ISV. ¡Un agradecimiento especial a mi colega Alba Rivas, quien me permitió probar su excelente Respuesta de StackExchange para la primera parte de este blog!

Parte I: ¿Qué es Lightning Web Security (LWS)?

LWS es una nueva arquitectura de seguridad del lado del cliente para Lightning Web Components (LWC) que reemplaza a Lightning Locker . LWS es menos restrictivo, pero tan seguro como Lightning Locker. En Spring '23, implementaremos una versión beta abierta de LWS para los componentes de Aura (se aplica el puerto seguro ). Cualquiera puede optar por esta versión beta activando una configuración en el menú Configuración de su organización (más detalles sobre esto más adelante en la publicación).

¿Cómo funciona LWS?

LWS sigue el modelo de los últimos estándares TC39 y evolucionará con las plataformas de navegador a medida que pase el tiempo. Los componentes están aislados en su propia caja de arena de JavaScript hecha de un iframe separado. Esto nos permite exponer objetos globales de ventana, documento y elemento directamente, sin abrir la puerta a amenazas de seguridad. LWS altera el código que se ejecuta en el espacio aislado de JavaScript para evitar comportamientos inseguros.

¿Cuáles son los beneficios de LWS sobre Lightning Locker?

LWS promueve el diseño modular, la reutilización de código y flexibilidad adicional. Con LWS puedes:

• Importe y use LWC de diferentes espacios de nombres mediante composición o extensión
• Interactuar con objetos globales (p. ej., ventana, documento, elemento)
• Use bibliotecas de JavaScript de terceros que manipulen objetos globales
• Acceda al contenido de iframe y a la identidad si el contenido es del mismo origen (nuevo en la versión Winter '23)

Para los ISV, LWS les permite anidar componentes de un espacio de nombres dentro de un componente de un espacio de nombres diferente. O pueden usar un LWC sin cabeza como una biblioteca JS de utilidad compartida que reside en un espacio de nombres de paquete "base" e importarlo a componentes de otros espacios de nombres. Estos casos de uso no eran posibles antes de LWS e ilustran las mejores prácticas en la reutilización de código. Como beneficio adicional, los clientes de un ISV también pueden usar los componentes con espacio de nombres del ISV dentro de sus propios componentes de la misma manera si el ISV ha expuesto los componentes.

Mientras que Locker no permite que los componentes accedan a objetos estándar globales como ventana , documento y elemento (los reemplaza con versiones de envoltorio seguro de estos objetos), LWS sí lo permite y también restringe menos propiedades y funciones relacionadas con estos objetos. Para ver la lista completa de diferencias, compare LWS Distortion Viewer con Locker API Viewer para cada uno de estos tres objetos (más información sobre estas herramientas más adelante). Un beneficio adicional de trabajar con estos objetos estándar directamente es la alineación con los estándares y sintaxis familiares para los desarrolladores web, lo que lleva a una mayor productividad de los desarrolladores al hacer que el código y los registros de depuración sean más fáciles de trabajar.

Sin embargo, el mayor beneficio de LWS que permite el acceso a estos objetos globales es que desbloquea la capacidad de usar muchas bibliotecas de JavaScript de terceros populares que no eran compatibles con Locker. La siguiente imagen muestra tres bibliotecas de terceros populares, D3 , Chart.js y FullCalendar , que funcionan dentro de una organización de Salesforce. Esto no era posible antes de LWS debido a las restricciones de Locker. La imagen también ilustra los componentes de un espacio de nombres anidados o importados en componentes de varios otros espacios de nombres. Como recordatorio, LWS actualmente es solo para LWC mientras trabajamos para lanzar LWS para componentes Aura.

LWS también proporciona un rendimiento mejorado en comparación con Lightning Locker porque no utiliza envoltorios seguros que pueden reducir el rendimiento. El equipo de ingeniería sigue centrándose en mejorar el rendimiento con cada versión.

La lista de beneficios de LWS crecerá con el tiempo a medida que introduzcamos nuevas características que requieren que LWS esté habilitado. Por ejemplo, estamos trabajando arduamente en funciones muy esperadas, como la creación de componentes dinámicos, así como las importaciones dinámicas para LWC ( puerto seguro ), que dependerán de que LWS esté habilitado en una organización para funcionar correctamente.

En el resto de esta publicación de blog, nos referiremos al grupo anterior de funciones que LWS hace posible como funciones "solo LWS".

¿Cómo puedo activar LWS?

Vaya a Configuración → Configuración de sesión y habilite Usar Lightning Web Security para componentes web Lightning . Esto afecta a todos los componentes de LWC personalizados en su organización, incluidos aquellos en paquetes administrados.

En Spring '23, esta configuración cambiará para habilitar LWS para los componentes LWC y Aura en la organización. El nombre de la configuración cambiará a: "Usar seguridad web Lightning para componentes web Lightning (GA) y componentes Aura (beta)" para reflejar esto ( puerto seguro ).

Parte 2: ¿Deberían los ISV adoptar características exclusivas de LWS hoy?

Recomendamos que los ISV esperen al menos hasta el verano de 2023 para adoptar funciones exclusivas de LWS para casos de uso de producción. Para los ISV que realmente desean usar las funciones exclusivas de LWS ahora, exploraremos sus opciones más adelante en esta publicación.

La razón por la que recomendamos esperar es que LWS pasó a estar disponible de forma general (GA) en la primavera de 22 solo para LWC . LWS para Aura todavía está en desarrollo y tiene como objetivo una versión de verano de 23 GA ( puerto seguro ). La activación de LWS en una organización que usa componentes Aura aún no es compatible * y puede causar problemas.

*"No compatible" significa que si surge un problema a causa de esto, el servicio de asistencia técnica de Salesforce no podrá ayudar a depurar y resolver el problema. No significa que los componentes de Aura dejarán de funcionar por completo.

Por esta razón, nuestra guía actual para los clientes que usan componentes Aura es habilitar LWS solo después de haber probado exhaustivamente todos sus casos de uso de componentes Aura en un espacio aislado con LWS habilitado. y siéntase cómodo habilitando LWS en producción, ya que LWS para Aura todavía está en versión beta hasta el esperado lanzamiento de GA en el verano de 23 ( puerto seguro ).

Esto significa que es probable que la mayoría de los ISV tengan una combinación de algunos clientes con LWS habilitado en sus organizaciones y otros sin él.

¿Cómo deben prepararse los ISV para LWS?

Dado que los ISV querrán incorporar nuevos clientes y brindar soporte a los clientes existentes que pueden o no tener LWS habilitado, deben asegurarse de que su aplicación funcione correctamente en organizaciones con y sin LWS habilitado.

Para asegurarse de que su aplicación ISV funcione en una organización sin LWS, no confíe aún en las funciones exclusivas de LWS (sin un plan alternativo). Los ISV no pueden asumir que LWS estará habilitado en todos los lugares donde se ejecute su aplicación, ya que algunos clientes aún no podrán habilitar LWS (p. ej., porque usan componentes de Aura que crearon o que están incluidos en el paquete de otro ISV y que tienen cuando LWS está habilitado o el cliente no tiene ancho de banda para la prueba de regresión).

Para asegurarse de que su aplicación ISV funcione en una organización con LWS, pruebe cualquier caso de uso basado en componentes de Aura en una organización que tenga LWS habilitado para asegurarse de que funcionen como se espera. Si LWS causa un problema (lo que es poco probable), proporcionamos algunas herramientas que pueden ser útiles para la depuración.

Diseñamos una lista de verificación para probar LWC con LWS. Esto puede darle algunas ideas sobre cómo hacer lo mismo con Aura. Por ejemplo, considere si algunas de las Reglas de ESLint pueden ser útiles en su caso, o consulte el LWS Distortion Viewer para ver si las API globales que está utilizando están restringidas por LWS.

Si no puede resolver el problema, considere si puede migrar su caso de uso de Aura a LWC, o dígales a sus clientes que esperen para habilitar LWS en sus organizaciones hasta que se resuelva el problema.

Una vez que se admite LWS para Aura, todas las organizaciones pueden habilitar LWS de manera segura. En este punto, Salesforce comenzará a activarse automáticamente y eventualmente implementará LWS en todas las organizaciones restantes en un cronograma gradual con mucha anticipación.

¿Cuáles son las opciones de los ISV para adoptar funciones exclusivas de LWS?

Opción 1

Espere hasta que todas las organizaciones puedan habilitar de forma segura LWS (Summer '23, puerto seguro) para distribuir funciones exclusivas de LWS a las organizaciones de clientes. Mientras tanto, puede experimentar con estas funciones, planificar el trabajo futuro o crear funciones en una rama de Git de larga duración que no se fusionará con la principal ni se enviará a los clientes hasta que LWS para Aura esté disponible en general. Esto se puede hacer ahora en el desarrollo de LWC; para hacer esto en Aura, mantén los ojos abiertos para un piloto de LWS Aura próximamente.

Tenga en cuenta que incluso cuando LWS para Aura esté disponible de forma general, todavía habrá muchos clientes que no habiliten LWS en sus organizaciones de inmediato. Confiar en funciones exclusivas de LWS en ese momento significa que es posible que deba persuadir a algunos clientes para que habiliten LWS (hasta que Salesforce aplique LWS para todas las organizaciones).

opcion 2

Verifique en tiempo de ejecución si LWS está habilitado en una organización y cree bifurcaciones lógicas en su código utilizando declaraciones if para manejar ambos escenarios (LWS está habilitado frente a LWS no está habilitado).

Tenga en cuenta que este enfoque no funcionará si el LWC de una aplicación ISV usa referencias estáticas de espacios de nombres cruzados. Estas referencias intentarían ejecutarse o renderizarse en la creación de instancias y no pueden ser bloqueadas por una declaración if. Esto provocaría un error en las organizaciones donde LWS no está habilitado.

Estamos considerando crear una forma con soporte oficial para verificar si LWS está habilitado en una organización desde el código ( puerto seguro ), pero por ahora, puede adaptar el siguiente fragmento de código:

Aquí hay un ejemplo de cómo usarlo para crear una lógica alternativa dentro de un LWC:

Nota: si bien esperamos que este patrón continúe funcionando cuando LWS para Aura se convierta en GA, le recomendamos que realice una prueba de regresión durante cada vista previa de la versión en cualquier lugar donde use este patrón para asegurarse de que continúe funcionando como se esperaba.

Opción 3

Mantenga dos paquetes separados : uno para organizaciones con LWS habilitado y otro para organizaciones sin LWS habilitado (o un paquete base para todas las organizaciones y una extensión solo para organizaciones con LWS habilitado).

Si bien la documentación analiza esta opción, y técnicamente se puede hacer, no es una opción viable en el uso real de las aplicaciones de AppExchange . Además de la carga de mantener varios paquetes, esta opción no es lo suficientemente ágil para situaciones en las que un cliente puede activar y desactivar LWS varias veces si descubre que causó problemas imprevistos. Esto puede provocar la rotura de las aplicaciones de ISV y es imposible de predecir para los ISV.

Para los estudiantes visuales, aquí hay un modelo mental para ayudar a los ISV a decidir si es seguro usar funciones exclusivas de LWS:

¿Cómo puedo obtener ayuda?

Para informar problemas, proporcionar comentarios y hacer preguntas sobre LWS, publique en el grupo Lightning and Components de la comunidad de socios. Si está informando un problema, abra también un caso de soporte y comparta el número de caso en su publicación con el grupo.

Si es un ISV que busca una consulta estratégica para alinearse con la hoja de ruta de Salesforce, necesita ayuda para planificar su estrategia de adopción de LWS o desea comprender las mejores prácticas y cómo incorporarlas en su aplicación, reserve una consulta de Platform Expert con mi equipo en cualquier momento.

Recursos

Sobre el Autor

James Quinn es un experto principal en plataformas ISV en Salesforce. Trabaja para facilitar la vida de los socios de AppExchange a través de la escucha activa de la comunidad, abogando internamente por la preparación de ISV de los productos de Salesforce y brindando a los socios orientación estratégica sobre la arquitectura del producto y las experiencias centradas en el ser humano.