Oopsie. Some poor bastard is having the worst day of their career.
I find it concerning that it was even possible for this to happen, regardless of whether it was intentional.
I find it concerning that it was even possible for this to happen, regardless of whether it was intentional.
I feel terrible for whoever initiated this. I’ve been in that boat and it -really- sucks.
"Ah yeah - it got in a bad state somehow, let me fix it manually"
UPDATE permissions SET allow = 1 WHERE user=671156 AND permission=16 AND org=101 OR 102;
* Change your account to readonly. Make a new admin account, and put its credentials somewhere hard to get (and audited!).
* Make a directory in git for 'one off sql statements'. Make them all go through code review and have an automated system run them on merge/deploy.
* Enforce style rules with a linter/test, like "UPDATE must have a LIMIT"
* Anything the above process is too burdensome to do should have an API or admin interface built for the purpose.
* Aim to eventually get rid of your readonly account. A leaked customer data dump could kill the company and shouldn't be available to any malware on your machine. You aren't as secure as you think you are.
I always recommend that you are wrapping calls in transactions if you are touching prod data. I only left the WHERE clause of my update query off once in my life before I started doing that.
BEGIN; UPDATE... SELECT for verification ROLLBACK;
And then just change ROLLBACK to COMMIT, after you're sattisfied. There's no need to do it interactively.
Do we have any example of any company going under due to a data breach? Unfortunately, there seem to be a lot of examples of enormous breaches that did essentially nothing. (like Experian)
As someone who has never had access to a DB with any serious number of users, can you explain this one further? What if you really do want to update every row? Do you just do LIMIT INT_MAX or the like, and just force people to write that so that they always know they're updating the entire table? Or are you saying you should only ever use UPDATE on a known finite (and small?) number of rows?
Basically, if your table is over a few gigabytes, updating every row in one query on a production instance is a really bad plan.
BEGIN; Statement COMMIT; or ROLLBACK
etc
It should be
UPDATE permissions SET allow = 1 WHERE user=671156 AND permission=16 AND org=101 OR org=102; (user=671156 AND permission=16 AND org=101) OR (org=102) (user=671156 AND permission=16 AND org=101) OR 102
org IN (101, 102)It is often worth running a SELECT on the WHERE clause you are about to use for your UPDATE. That way you can make sure only a limited amount of data comes back before you launch something catastrophic.
Also incorrect, they have great cloud and devops practices. If anything it's likely this bug's impact would be limited due to how decentralised SFDC operates.
Still a massive fuck-up, I'm interested in seeing if they'll release any more detail on why it happened.
whaaaaaaaaaaaaaaaaat hahahaha i can't take that seriously; I've used it and it felt like a giant pit of despair
Impossible to run locally.
No debuggers.
Virtually impossible to put an entire org in source control.
No package manager.
More undefined behavior than a C compiler.
they do own heroku
SFDC hate is pretty common, maybe because of how big they are. I think that their tech is actually pretty impressive.
Like seriously I would rather lick alcohol soaked razor blades than do a standard annual renewal of a Salesforce contract.
That's the advantage of decentralized architecture. It's a disadvantage too though ...