Lightning Locker is enabled by default for all new Experience Builder sites. However,
occasionally a third-party component on the page or custom code in your head markup doesn’t work as expected due to a conflict with
Lightning Locker. In such a situation, Salesforce recommends using one of the workarounds
described here.
Use JavaScript Custom Events
Lightning Locker protects third-party components and custom code from interacting with
resources from other namespaces, but not from the head
markup. This limitation means that your head markup can
contain custom code that bypasses Lightning Locker and introduces security vulnerabilities.
To address this limitation, isolate your third-party Aura and Lightning web components and
custom code by using the CustomEvent constructor in
your head markup. Third-party components and custom code
can then interact with your resources without the responsibility for loading or referencing
that resource directly.
Any data that must be passed through the event to the listener is passed in the detail property, which is created when initializing the
event. The detail property is mapped to the
dataLayer in your head markup listener. The custom events
are then dispatched to any resource that extends EventTarget. For an example of using custom events, see Adobe Analytics and Lightning Locker.
Be aware of the data that you’re passing with the JavaScript CustomEvent constructor, and ensure that your usage is
secure. Any JavaScript running on your page (including any third-party App Exchange
components that you’re using) potentially can listen for your event names and read this
data.
Set an Aura Component to API 39.0
If your third-party component or custom code doesn’t interact with an Aura component as
expected, you can set the Aura component to Salesforce API version 39.0, which disables
Lightning Locker for the component. See
Disable Lightning Locker for a Component in the
Lightning Aura Components Developer Guide.
Disabling
Lightning Locker for an Aura component can introduce security flaws into your site and
prevent the component from being available at design time or rendering at
runtime.
For consistency and ease of debugging, avoid having a parent Aura component and a child
component on different API versions. Therefore, any Aura component set to API version 39.0
shouldn’t be used in a component hierarchy, such as a component within a component or a
component that’s extending another component.
Turn Off Lightning Locker
Use this workaround only
as a last resort.
If you turn off Lightning Locker in your site, you disable it for
all your site’s third-party components and custom code. The ramifications can be
far-ranging and unexpected, such as introducing security flaws into your site. And if a
third-party component hasn’t been
enabled to work without Lightning
Locker, it can prevent that component from being available at design time and
rendering at runtime. When Lightning Locker is turned off, components from different
namespaces can interact with and access each other’s DOM, and restrictions around custom
resources interacting with your site are relaxed.
See Select a Security Level in Experience Builder Sites
in Salesforce Help for more information on disabling Lightning Locker.
j