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 

The Case of the Missing Mascot

Introduction

There's just over a day to go to help the Trailhead team in the search for missing mascot Astro, so if you haven't already pitched in, get yourself over to :

https://developer.salesforce.com/trailhead/module/wheresastro

where you can earn the badge and even get the chance to win a prize*

Where’s Astro?

This is a somewhat different module to the others - rather than learning about a particular feature of Salesforce and then answering some questions or completing a challenge, you are instead helping to solve a mystery (where is Astro) by searching for clues in the Trailhead content.

The clues will direct you to other modules, so if you don't have the badges for those (really, you don't have them all?) its a perfect opportunity to improve your Salesforce knowledge while investigating. If I'd been setting this up we'd have to complete the modules, but the Trailhead team were clearly overwhelmed with worry about their missing mascot and went easy on us.

Of course, it wouldn't be Trailhead if you didn't have to carry out some setup and configuration,so you can expect to track the progress of your investigation in a Salesforce Developer Edition, much like Sherlock Holmes would, if the modern version wasn't on the BBC and thus not allowed to advertise products :)

There's no coding involved, and the setup is pretty straightforward, so this is very much a module for all (or no!) skill sets - when a mascot's life hangs in the balance you need all the help that you can get, especially people that aren't averse to leaving their computer and going outside!

Keeping Everyone in the Loop

One aspect that I particularly liked were the tweet buttons at various points that posted out cryptic updates about progress:

a great way to get others interested and let the concerned population know that the search continues at full steam. Continuing with the Sherlock Holmes association, this is the modern equivalent of the agony columns that featured in many of the stories.

Leaving Everyone Hanging

The first rule of earning the Where’s Astro badge is that you don’t talk about the outcome of the investigation. If you don’t complete this module yourself you’ll have to wait until the Trailhead team spills the beans some time after the competition closes, and I hope you can live with yourself in the meantime.

As mentioned earlier, the search finishes on April 14th, so get your magnifying glass and deerstalker hat and join in while there is still time.

Follow @bob_buzzard

* Confession time - I didn't realise this was a competition until earlier today. What happened, as is always the case, is that I saw a new badge was available and I had to have it :)

Fantasy Trailhead #1 - Maximum Damage

(Note - this is a humorous post - if you follow any of the advice below your experience will be sub-optimal, but also hilarious, so make sure to let me know just how bad things turned out)

Introduction

After finishing up my 102nd Trailhead badge a couple of weeks ago, I started thinking about badges that I’d like to see in the future. Before long I’d changed to thinking about badges that we’re never likely to see, which are awarded for doing things badly as opposed to well. To that end, allow me to present my first Fantasy Trailhead - Maximum Damage

A Trail for Everyone

As everyone involved in implementing or maintaining a Salesforce instance has an opportunity to cause damage, this Trail covers the whole range of skills - Admin, Developer and Architect. The aim is to answer questions/implement challenges in the way that would cause maximum damage to an instance. 

Clicks not Solutions

Admins are every bit as powerful as developers when it comes to breaking Salesforce and in the Maximum Damage trail they would be expected to understand not just the terrible impact of their changes on the Salesforce platform, but also the deleterious  effects on their business as a whole. Here’s an example question:

“A user would like a mechanism to ensure that they cannot save a Contact record without populating the Other Phone number. No other users are expecting this change and in the majority of cases this information will not be available”.

In a normal universe this request would be rightly rejected, but in the Maximum Damage Trail we leap on it with gusto. The answer options as as follows, along with an explanation of why the are not the right (or the most wrong!) solution:

1. Add a validation rule that checks if the Contact is being created by the particular user that requested the change, if it is then ensure the Other Phone field is populated.
   This is a reasonable solution to the problem, and therefore not what we are looking for in Maximum Damage - there are no additional unwanted features and other users won’t even know the change has been applied.
    
2. Make the Other Phone field required on the Contact page layout
   This is better, as users who do not want this change are being affected by it and their working lives have been made a
   little more difficult. One downside to this is that no existing integrations have been broken, as this is only affecting the UI.
    
3. Make the Other Phone required through Field Level Security
   Now we are starting to see some serious damage - integrations and automated loads of Contacts are likely to be impacted, but this is still relatively localised to Contact creation. Is there any more that can be done to cause problems for the wider business.
   
   
4. Make the User a System Administrator so that they can make the Other Phone required through Field Level Security
   This is taking the long view with regard to ruining your implementation - all the downsides of answer 3, plus the user is now empowered to make whatever changes they like to any part of the system. hopefully without any idea of the impact of their changes. It might seem that we’ve taken this as far as we can, but things could be worse.
    
5. Share your username and password with the user so that they can make the Other Phone required through Field Level Security
   This is the gold standard - all of the downsides of the previous options, plus a lack of accountability. When the user makes the inevitable badly thought out change, nobody will know it was them and it will look like you did it. This will muddy the waters nicely, as your co-administrators will assume you had a good reason and hopefully spend valuable time trying to understand why.

 Future-Resistant Code

The Developer module in the Maximum Damage Trail is designed to test your ability to produce the worst possible coded solution to a problem that didn’t need code in the first place. Rather than taking the YAGNI (You Ain’t Gonna Need It) approach, not worrying about future requirements, solutions here use a YAGGI (You Ain’t Gonna Get It) approach, producing code that cannot be extended in the future.

This module is more challenge based, and looks for solutions with the following attributes:

• Replicating standard platform functionality, badly.
• Use of hardcoded ids wherever possible
• Only capable of handing a single record, to ensure that data migration is as painful as possible
• SOQL queries and DML statements inside loops (preferably loops that are nested for no good reason).
• No unit test coverage
• Any inputs other than those specified in the challenge would cause the code to fail
• Consuming as many governor limits as possible without breaching, to ensure that this cannot be added to an existing business process with code.
• No error checking or validation of inputs
• Empty catch blocks should be liberally used to swallow any exceptions and plough on regardless.

Technical Incompitecht

The architect module of Maximum Damage looks for decisions that will not only inhibit scale, but also maximise costs throughout the lifetime of the implementation. Fittingly, I’m not sure how well this would scale from a marking perspective, as there would be some subjectivity here so they would probably need manual marking. The Maximum Damage Trail also takes down the author!

Key features of the solution architecture include:

• Overloading a standard object to provide custom functionality
  This would involve creating a number of new fields which have no relation to the standard object and removing any standard fields from the page layout. Record types must be avoided, as this provides an unwanted degree of separation. Using a standard object in this way maximises the license cost, and the standard object should preferably be one requiring an additional, paid, feature license.
• Using a Community to do a Force.com Site’s job
  It goes without saying that named Partner Community licenses should be used, especially if high volumes are required as this will guarantee a scalability problem before too long.
• Complex security and sharing
  Org wide defaults should always be Private. If public access is required this should be implemented by multiple sharing rules at the lowest possible level of the role hierarchy possible. Territory management is a must, unless the requirements indicate territory management, in which case it should be avoided at all costs.
• Little or no Change Control
  An architect should not miss the opportunity to make the development lifecycle harder than it needs to be, so a change control process involving as manual replication of configuration and hand-deployment of code via the Force.com IDE will score highly.
• Centre of Negligence
  The antithesis of a Centre of Excellence, an architect is expected to identify a governance framework that leads to isolated decision making with no idea of the needs of other business units or the organisation as a whole.

Only Joking … Or Am I?

While I put this post together for a bit of fun, I think there is value in being able to identify the worst solution from a selection of bad options. Most test/exam questions have one correct answer and the others, while plausible, will be flawed in some way. This means that you can figure out the correct answer even if you don’t know it (I’m fond of quoting Sherlock Holmes in this regard - “When you have eliminated the impossible, whatever remains, however improbable, must be the truth”).

Being presented with an entire list of flawed options and having to choose the one which will cause the most problems both now and in the future requires an in-depth understanding of how customisations affect the Salesforce platform, and how seemingly minor decisions can cause major problems in the future.

I have a couple more ideas for Fantasy Trailhead, so stay tuned for more posts so set you on the path to failure.

 Follow @bob_buzzard