Locker Service and the Lightning Container Component

Securely Using Third-Party Libraries in Lightning Components

LockerService is a powerful security architecture for Lightning components. LockerService enhances security by isolating Lightning components in their own namespace.

LockerService also promotes best practices that improve the supportability of your code by only allowing access to supported APIs and eliminating access to non-published framework internals.

In Salesforce Platform application composition infrastructure is provided by the Lightning Component Framework.

This allows you can extend and customize these apps with your own components, or create completely new apps.

The components you assemble can come from different sources:

  • Salesforce components
  • Your own components
  • 3rd party components

Components can be built entirely from scratch or by leveraging third-party libraries.

Two isolation mechanisms that allow you to use them securely and avoid security exploits.

  • LockerService
  • Lightning Container Component

3rd libraries

  • DOM manipulation libraries (jQuery, etc)
  • Specialized utility libraries (moment.js, numeral.js, etc)
  • UI libraries (Bootstrap, jQuery UI, etc)
  • Data visualization libraries (D3, Chart.js, Leaflet, etc)
  • MVC frameworks (React, Angular, etc)

DOM manipulation libraries (jQuery, etc)

Task: Set the value of a score input field to 100.

In jQuery:
// Markup:
<input id="score" />
// Code:
var scoreElement = $("#score");
scoreElement.val(100);
In Lightning Component Framework:
// Markup:
<aura: attribute name="score" type="integer" />
<input value="{!v.score}" />

// Code:
component.set("v.score", 100);

In the Lightning approach, the model and the view are decoupled:

  • your code doesn’t have to reach into the DOM (no direct DOM access)
  • This leads to more robust and more maintainable code
  • Avoiding direct DOM manipulation is a best practice in the Lightning Component Framework

UI libraries (Bootstrap, jQuery UI, etc)

The following offer similar capabilities (that UI libraries provide) while providing a consistent user experience:

  • Base Lightning Components
  • Lightning Design System

MVC frameworks (React, Angular, etc)

Lightning Component Framework can provide code organization and utilities to create components and also it’s tightly integrated with the platform.

If you need to use them, choose the isolation mechanism : LockerService or Lightning Container Component) that works with your framework to avoid security exploits.

Avoiding Security Exploits

  • Provide the right level of isolation between components
  • Untrusted component shouldn’t be able to gain access to the part of the DOM owned by another component
  • Without the right level of isolation, a vulnerability in one component can provide access to sensitive data in other components and jeopardize the security of the entire system
  • Each component you use can become an application is an attack vector

LockerService

LockerService is discussed here

Lightning Container Component

Lightning Container Component is discussed here

Summary

Before you decide to use a third-party library in a Lightning Component:

  • You should reevaluate if you really need that library.
  • DOM manipulation libraries and UI libraries in particular may no longer be needed when working with the Lightning Component Framework.
  • LockerService is the preferred isolation mechanism and should be your first choice because it’s more tightly integrated: components run in the same DOM, resulting in a faster and more cohesive user experience.
  • If your library doesn’t support LockerService, you can fall back to iframe-based isolation using the
    lightning:container
    component.

Comparing LockerService and Lightning Container Component

LockerService Lightning Container Component
iframe-based No Yes
Components are loaded in the same DOM Yes No
Supports all third-party libraries No. Only compliant libraries will work. Yes. Libraries are sandboxed in their own DOM/context.
Cohesive UI Components can grow and shrink. Surrounding DOM elements will reflow. Components are constrained by iframe boundaries
Inter-component communication Native LC communication postMessage
Performance Faster. All components are loaded in the same DOM. Slower/Heavier. Each iframed component has to load its dependencies.

References

results matching ""

    No results matching ""