So-Called Advent Calendar Day 22 - A Lesson In Hot Dogs

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.

sandwich alignment chart
In sandwich lore, the hot dog means unity

Are hot dogs sandwiches?

It’s a highly contested that brings up strong opinions. People site evidence from New York tax code and from an interview with Supreme Court Justice Ruth Bader Ginsburg, hoping to fortify their position. Yet despite this evidence, the debate is far from over.

But instead of taking another position, I wanted to take this opportunity to dive into the hot dog’s position on the sandwich alignment chart. It sits right in the middle, as a true neutral between ingredients and structure. And by sitting in this position, it is on the fringe of not only the sandwich definition, but also the wrap defintion, and the taco definition.

A common argument I often hear is “If someone said they are bringing out a plate of sandwiches and they came out with hot dogs, wouldn’t you be surprised?” Of course, but the same thing applies if you replaced “sandwich” with “wrap” or “taco”. Hot dogs are at the nexus of these handheld meals.

If you were eating hot dog and the bun split into two, does that suddenly make it a sandwich? Or if you have a really doughy bun and you squeezed your hot dog to close the bun loop, is it suddenly a wrap? What if you didn’t have a bun, but you had flour tortillas - does that make your hot dog a taco?

With just minor adjustments, the hot dog can jump between so many categories. Instead of focusing on the differences, the unification power of the hot dog forces to look at our similarities.

We love to take sides, but sometimes we let the sides divide us. Tabs vs. Spaces. Agile vs Waterfall. Star Wars vs. Star Trek. PC vs. Mac. Digimon vs. Pokemon. Batman vs. Superman (GREAT movie btw).

So during this holiday season, when you take a bite into that traditional Christmas morning hot dog, take a lesson from the hot dog and try to remember the bridges that joins us together, instead of the breads that try to keep us apart.

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.