Saturday 16 April 2016

The Hurt Locker

The Hurt Locker



There’s a new Sheriff in Lightning Town and its name is the LightningLocker. The purpose of this is to tighten up security around Lightning Components, something that has been mentioned in the documentation, usually along the lines of "you shouldn’t do this, and while it might work at the moment, we may stop it in the future”.  Well the future is starting in Summer 16 when the LightningLocker becomes available as a critical update for existing orgs and the default for new orgs. I’ve always suspected the Lightning Components present a real concern for the Salesforce security team, as our JavaScript is co-existing with Salesforce JavaScript and has the same powers, well not any more! This is something to be welcomed, not only from the perspective of stopping nefarious JavaScript from causing problems, but also because a lot of developers will be learning JavaScript on the jon as they develop their components, and its pretty much a given there will be some unintended consequences which may be severe.

But What if I Really, Really Need To ...

Now obviously I’m not Salesforce, so I can’t say for sure if they will make any exceptions, but I’d be pretty surprised if they do. The Locker isn’t closing down loopholes because they are worried the world may be blinded by the sheer awesomeness of your solution. Loopholes are being closed because they are a security risk, and whitelisting applications to punch holes in security is unlikely to make customers feel safe.

It’s So Unfair - I Hate You!

It isn’t really - we all knew this was coming. I view it in a similar vein to JavaScript in Home Page Components - if you were told not to do something and did it anyway, don’t expect any sympathy when the capability is taken away (and yes, I know I was wrong about Salesforce providing a replacement - that should have been customising standard pages with Lightning Components which has taken way longer to arrive than I expected - currently still in pilot for record home pages!). That said there are a couple of things that concern me:

  1. This should have been in place from the start
    It’s all well and good putting warnings in the docs, but out in the real world people have hard deadlines and requirements, and not everyone reads the docs before making a questionable decision. I’m sure there are some customers out there who have components where the original developer has since departed or was never on staff. If their components are using anything that the Locker takes issue with, they could lose key functionality without the in-house skills to replace it.

    If you think about it, this is like carrying out a Salesforce implementation and giving every user System Administrator privileges with a warning not to rely on them, then coming back after a year or two and changing them to a Standard User. While you can say that you warned them, and its not your fault if their business processes relied on their elevated privileges, you aren’t going to be popular.
  2. Should we expect breaking changes?
    I’m raising this as its something which I think I’m likely to fall foul of. To use inheritance in Lightning Components I’m making  use of the component.getDef() method to access the ComponentDef and then executing the getHelper() method. However, ComponentDef has been removed from the Lightning documentation app, which suggests that it isn’t supported - per Skip Sauls reply in this thread

    "JavaScript source is not documentation, and does not indicate support. Please refer to the docs for the official API. Use of unsupported components, events, or APIs is a violation of the terms of service, and your code may break in a release, including patch."

    But here’s the rub - this did appear in the documentation, and then it went away. So where does that leave me? I’ve raised this on Stack Exchange where I know a lot of the Lightning team lurk, so if I get an answer I’ll update this post.

  3. I Want Workarounds!
    Thus far I’ve seen mentions of tools, blogs, articles and Trailhead modules to help us get to grips with this. What I haven’t seen mention of is alternatives. If I’ve gone to the open source Aura project to figure out how to do something, and that turns out to be a private API, I’d like a workaround providing equivalent functionality rather than just being told I can’t use it any more. I only resort to the Aura source if the documentation app isn’t helpful (sadly this happens more than you’d expect, as there are still a number of entries that just have the method signature/component name and no additional information).

There’s an app for that 

If news of the Locker makes you fear for your code, there’s an app (or more accurately, a command line tool) that can give you some succour - the Lightning CLI. I’ve run this on some of my components and it has raised a few things that I need to take care of (although doesn’t have a problem with ComponentDef mentioned above, but I’m not reading too much into this at the moment).

The Hurt Locker? Seriously?

Like I could leave that alone!

Related Links



  1. Bob,

    This is a great post. Thanks for sharing some sneak peak on security changes in Summer'16.

    I am trying out a few things with lightning components in a GS0 org with summer'16 and running into an issue.

    In my lightning component, I have a UI wizard that gathers data from the user, its then supposed to create a new record by specifying the record type of this record (based on the collected data). But when I try to use "createRecord" from within my component it fails.

    Can you help me to use basic lightning capabilities like navigating to a record, editing a record, etc from within my custom lightning component?

    Thanks n Regards,

  2. With regards to the Lightning CLI, I have added support for this in the Lightning Sublime plugin! After installing the Lightning CLI plugin to the Heroku Toolbelt, update to the latest version of the Lightning Sublime plugin. On file save the linter will run and any warning will be highlighted in the Sublime code editor!

  3. This comment has been removed by the author.

  4. Thanks Bob,

    "You shouldn’t do this, and while it might work at the moment, we may stop it in the future”. It seems that "You should not use external js libraries at all". For example I implemented google libphonenumber js, no problem with VF but with service locker all library methods are undefined in lightning, CLI shows also just undefined. Even if you tried to do kinda j$ = jQuery.noConflict(); jquery 224 - j$ is undefined. Were you facing similar issues?

  5. I too just ran into this issue with a lightning app I'm designing. My external library was undefined until I disabled LockerService in my org. What is the correct way of using external libraries in conjunction with Locker Service?