Lightning components and locker service

Question

I am trying to get a hang of what is accessible via locker and what elements are not. Following through threads in this forum, I realized there are some components that are genuinely locked by locker service and there are some that are user errors. I am having hard time isolating the noise from the real issues caused by locker service.

As per docs the golden rule seems to be locker will not allow access to any component that is not served from the same namespace. If this is the case why are people complaining about locker disabling access to Jquery, full calendar kinda external libraries when loading from static resource with locker service enabled?

eg:Cross-Origin Frame Error in Lightning Component embedded in Salesforce Console

Issues with running LockerService, d3, and Lightning components

The docs :https://developer.salesforce.com/blogs/developer-relations/2016/04/introducing-lockerservice-lightning-components.html say

Can I use 3rd party libraries (React, Angular, etc) if running in Locker?

**Yes, provided they are served from Static Resources and approved by security**.

1) Is there a comprehensive doc that shows what is not accessible and what is accessible when locker is enabled? I see a conditional clause of if approved by security, is there a list of what's approved by security?

2) With summer 17 locker will be enabled by default. Is there a global variable/method that will indicate if permission to access a DOM element is granted or not?

I am thinking along the line of iseditable(), isdeletable() in apex terms. If the component is denied access due to locker service is there an easy way to check

if(lockerprovidedaccess){
 console.log('Locker granted access, do all manipulations you need to');
}
else{
console.log('Locker disabled access');
}

Correct me if I am confusing myself with too many terminologies.

Answer 1

Too much for a comment but important to note:

Right now, there is a lot of noise. Other than the general rule it is hard to tell what is a bug, user error, or not allowed. I believe this is a consideration with the recent notification that the Enablement of Locker service this summer can now be rolled back by the admin rather than being permanent using API versioning

Received on 4-28-2017

In Summer '16, we introduced LockerService as a Critical Update. We planned to enable LockerService, including stricter Content Security Policy (CSP) in all orgs, starting with Summer '17. However, based on customer feedback, we have revised our rollout plan.

(Emphasis Mine)

With the revised rollout CSP has been decoupled from LockerService and won't be enforced in production orgs in Summer '17, and now you have the option disable LockerService by adjusting your API version.

LockerService Enforcement is Dependent on API Version LockerService is enabled for all Lightning components with API version 40.0 (the version for Summer '17) or higher. LockerService isn't enabled for components with API version 39.0 and lower, which covers any component created before Summer '17.

To enable LockerService for a component, set the API version to 40.0. You can disable LockerService for a component by setting the API version to 39.0 or lower for the component.

Component versioning enables you to associate a component with an API version. When you create a component, the default version is the latest API version. In Developer Console, click Bundle Version Settings in the right panel to set the component version.

Stricter CSP Restrictions Aren't Enforced Yet The stricter CSP restrictions, which mitigate the risk of cross-site scripting attacks, have been decoupled from LockerService and aren't enforced in production orgs in Summer '17. The stricter CSP changes are available only in sandboxes and Developer Edition orgs and can be activated in two new critical updates:

• Enable Stricter Content Security Policy for Lightning Components
• Enable Stricter Content Security Policy for Lightning Components in Communities This gives you more time to update your code to work with stricter CSP.

Answer 2

Aura (Lightning's underlying engine) runs in two modes: system-mode and user-mode (or, "trusted" and "untrusted"). Trusted code is written by salesforce.com and boots up before any components are loaded. It has full access to the entire DOM. Untrusted code, in contrast, is written by someone that isn't salesforce.com, and only has access to its specific shadow DOM. This isn't domain-based, but rather DOM-based. Each component can only see what it has access to within its current DOM, but may communicate through approved channels (namely, Aura events).

The determining factor if a library will work or not is if it conforms to well-defined behavior in regards to the DOM. If it tries to step outside of its own shadow DOM, it will be blocked by the security measures of Locker Service. The allowed operations are defined by if they can be used to subvert the security measures in place. Security doesn't literally check every single library and individually stamp a seal of approval. After all, a developer could tweak the code slightly by using conditional compilation, etc. Instead, they analyze the code statically to see if it works as is, and if not, they add exceptions to allow the library to work, as long as it would not subvert security.

As a developer, we can see the secure API that outlines what a library can or cannot do. As long as it obeys the rules, it is free to operate as it desires. In addition, CSP (Content Security Policy) prevents arbitrary loading of resources, which is why there's an additional caveat that the code must live in a static resource or inside a Lightning bundle. Security has tested several different libraries outlined here. The list is not comprehensive and doesn't even guarantee other versions of the library may or may not work. You can write your own libraries, as long as it conforms to the security outlines, and it'll run just fine.

In many cases, sometimes a recent tweak to security may render a library unable to load. In these cases, sometimes the library needs to be patched, or the security rules reworked to allow the library to run normally. In addition, even if the library is perfectly solid, some extensions/modules may violate the rules, and they won't work. For example, jQuery works just fine, but if you try to use module XYZ, it may not work. Or, the library works but the user's code is at fault.

So, as far as things go, developers interested in what's allowed should check the Locker Service API (above). By using only approved properties and methods, the library should work seamlessly. It also gives you a decent idea of things to look for when things go wrong. You can catch access exceptions if you're not sure Locker Service is enabled or not, but there's no general purpose API that just tells developers if Locker Service is enabled. Developers should always develop with Locker Service enabled to make sure they're in compliance.

There's an image located here that basically describes how things work. For today, components are sandboxed by namespace, but the article also outlines that components will most likely be sandboxed per-component in the future. Components should always strive to respect their own borders and use only approved methods for communicating outside of its own DOM.

Answer 3

Noise you see can be from multiple places, it might Salesforce side issue or custom development issue; the dark reality is its pretty hard to debug from what/where/who causes the issue.

Main goal of Locker Service is provide a proper isolation between components as well security to the elements of the component you do not own. As the golden rule states,

you cannot access the DOM of the components you do not own.

Locker Service not only locks you from accessing stuffs you do not own also it enforces security defence mechanism like Content Security Policy and strict mode.

How it is enforced?

As part of Locker, Salesforce has overriden the DOM/BOM API available in the browser by their own implementation which enforce DOM access/managing restrictions laid out by them thus, enabling security and component encapsulation. So in simple terms if you do :

document.getElementById('myDidv') - you are calling SecureDocument's(overriden custom version of document object) getElementById method not the actual document object available in the browser.

Same applies for window and element object whose custom implementation is referred as SecureWindow and SecureElement.

To your question, why does some of the 3rd libraries makes noise when locker service is enabled ?

Since we are dealing with custom version of native document,window and element. Also not all 3rd libraries are strict mode complaint which also impacts too. Inaddition to that, other issues in 3rd party js might be because of:

1) Usage unsecure API methods which were blacklisted and are not supported.

2) Usage of the some standard/new API methods that are not yet supported.

3) Internal issue with custom API implementation in Locker which causes unexpected behavior in 3rd party JS.