So-Called Advent Calendar Day 21 - What we can learn about Imposter Syndrome from Chicken Boo

In the spirit of the holiday season, this is a series of short blog posts covering random things I have learned while doing Salesforce development, one for each day of Advent.

chicken boo
You wear a disguise to look like human guys, but you're not man, you're a Chicken Boo

In the 90s cartoon Animaniacs, there was a recurring character named Chicken Boo, a giant chicken that would wear a disguise to try to fit into some human profession. The bit was pretty simple - Chicken Boo would wear the disguise to do something, like fight in the civil war, pose as a secret agent, enter a martial arts tournament, or be a mall Santa Claus. The disguise would do little to hide the fact that he was a chicken, but he was only revealed at the end of the episode when his disguise fell off.

I always loved Chicken Boo and I still sing the theme song from time to time:

But I think there’s a valuable lesson here. Something that I see a lot of developers struggle with is Imposter Syndrome - this idea that you have somehow fooled everyone into thinking that you are something you are not. That the interview was a fluke, that the feature you built was just luck, that you’re just a professional googler jamming things together.

The end of every Chicken Boo is the Imposter Syndrome worst nightmare - you are revealed as a fraud and everyone finds out the truth - you’re actually a giant chicken a terrible developer.

While it doesn’t end well for Chicken Boo, he always comes back to try again. And that’s weirdly inspirational. Because we all put on a kind of mask, a bit of a disguise, to be someone that we want to be, but fear that maybe we aren’t that person. But you are what you do. Chicken Boo really was a network executive, a ballet dancer, and a cowboy - in each episode he gives it his all and he nails the job.

And that’s all you can really expect from yourself too - build to the best of your ability, learn from your mistakes, and keep going every day, no matter how many times you feel like a giant chicken.

So-Called Advent Calendar Day 20 - Securing Your SOQL

In the spirit of the holiday season, this is a series of short blog posts covering random things I have learned while doing Salesforce development, one for each day of Advent.

clicking on the word security
Just click the secure button and we should be secure

A common misconception I have heard is that using with sharing when declaring an Apex class enforces security in your code. However, that only enforces sharing rules, i.e. it prevents the running user from querying and updating records that they do not have sharing access.

It DOES NOT enforce FLS. Even if the running user does not have read/edit access to a field on an sObject, when that field is queried in Apex, that field will be populated. Using <apex:outputField> in Visualforce will prevent the user from seeing the value, but the value is still fetched in apex.

There are two security mechanisms in Apex that are in beta that can really help you enforce field level security in your code.

The SOQL clause WITH SECURITY_ENFORCED
The stripInaccessible method

Salesforce documentation does a great job outline how they work, but they are not interchangeable.

WITH SECURITY_ENFORCED

When the clause WITH SECURITY_ENFORCED is added to SOQL query, if the running user does not Read access to any of fields in the SELECT statement, an exception will be thrown. For example

List<Account> accounts = [SELECT Website FROM Account WITH SECURITY_ENFORCED];

This query will throw an error if the running user does not have Read access to the Account.Website field. It only applies to the SELECT statement. For example:

List<Account> accounts = [SELECT Id FROM Account WHERE Website = 'socalledprogrammer.com' WITH SECURITY_ENFORCED];

Since Account.Website is not included in the SELECT statement, this won’t throw an error even if the running user doesn’t haven’t Read access to the field.

So with a single statement, you can start enforcing field level security in your queries. However, the downside is that the query fails hard and the error message does tell you what field is needed. Also, I have seen it used with queries that try to emulate SELECT *, which means that EVERY field on the object needs to be readable by the running user in order to run at all. So while the query is secure, to get the app to run at all you’d have to grant access to every field on the object, defeating your security effort. Luckily Salesforce provides an alternative.

The .stripInaccessible method

The stripInaccessible method is a little more nuanced and does the check after the query is made. Here’s the example from Salesforce’s documentation:

List<Account> accounts = [SELECT Name, Website FROM Account];
SObjectAccessDecision decision = Security.stripInaccessible(AccessType.READABLE, accounts);

for (Integer i = 0; i < accountsWithContacts.size(); i++) 
{
    System.debug('Insecure record access: '+accountsWithContacts[i]);
    System.debug('Secure record access: '+decision.getRecords()[i]);
}

// Print modified indexes
  System.debug('Records modified by stripInaccessible: '+decision.getModifiedIndexes());

// Print removed fields
  System.debug('Fields removed by stripInaccessible: '+decision.getRemovedFields());

This gives you a little more control because you make a decision based on the results of the security check. For example, you could log an error for an admin to check to later to see if there are missing permissions, or if someone is trying to see something they aren’t supposed to.

To be honest, I can’t think of a really good reason to use WITH SECURITY_ENFORCED. The error it throws is too vague and it makes it really hard to debug. But it’s good to know there is a quick option to bail hard on a query if the running user doesn’t have the necessary permissions.

These items are still in beta, but I would give them a try. Security often gets forgotten when writing Apex, so it’s nice to have additional easy to use tools to make things a little more secure in your code.

So-Called Advent Calendar Day 19 - WhatsThis.js

In the spirit of the holiday season, this is a series of short blog posts covering random things I have learned while doing Salesforce development, one for each day of Advent.

Jack skellington
JavaScript Town isn't nearly as exciting

The “this” keyword can be hard to wrap your head around, and I personally have wrestled with it for a long time (which makes me think it’s a language problem and not my fault! But I digress). So while I was trying to learn how to use it, I found it was much more fun to sing about it!

Here’s a song I wrote a few years ago about this:

WhatsThis.js

(to the tune of ‘What’s This?’ From The Nightmare Before Christmas)

What's this, what's this?
My scope is everywhere.
What's this?
And now it isn't there.

What's this?
Call, apply and bind,
What am I typing
setTimeout? This isn't fair!
What's this?

What's this? What's this?
I guess I'll check this blog
What's this?
Now try console.log()

What's this?
The code is lined with
debugs laughing
breakpoints trying to see what's happening
Have I possibly gone daffy?
What is this?

What's this?

There's functions throwing exceptions
undefined it said
Suddenly it's working
And now my code is dead

this is equal to the window?
Oh, I can't believe my eyes
This async function has a new
scope coming from inside...

Alert! What's this?
They're binding to the scope! Var that?
That is still defined! Inspired!
This is set to that to keep this constant
Every single time it fires
What's this?

What's this?
Right here! A method named call? How queer
And who would ever think?
Apply?

This is bound to all sorts of things
Following a call stack like a string
And there's a smile on everyone
So now correct me if I'm wrong

This is dumb!
This is fun!
Oh, could it be I got my wish?
What's this?

Oh my, what now?
A callback argument?
But look, call() cannot be sent
Or apply(), no parameters to declare them
Or ensnare them, but bind() ensures that they are
Defined inside this function... hmm....

What's this?

This is still just missing
The scope cannot be found
And in their place there seems to be
Undefined's all around

Instead of binding correctly
Another var I have to declare
The sight of programs crashing
Are absolutely everywhere

The stacks, the calls!
They're everywhere and all, around
I never felt so confused, before!
This implied scope keeps hoisting up
I simply cannot get this function up

I want this, oh I want this
I want this to be known
I've got to know, I've got to know
Is there a syntax that is sound?
What! Is! This!

Arrow functions? Hmm…