The Hurt Locker

Introduction

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

• Introducing The LockerService For Lightning Components
  (The official Developer Relations blog post that scared me!)
• Lightning CLI Package home page

Follow @bob_buzzard