Timeline for Security Review Preparation: Checking isAccessible on each object and field in complex SOQL queries for whole codebase
Current License: CC BY-SA 4.0
6 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Dec 31, 2018 at 8:49 | comment | added | wesaw | We have more than 10,000 places in our code base where SOQL queries are used, so even adding one simple call to helper class is sort of a problem for us. Plus it's hard to rely on developers to strictly follow this approach and update list of fields appropriately every time when they add/update/remove something from related query. And yes, when SF makes CRUD checking as a part of a platform, I would rather drop all home-made or third party solutions and switch to standard one - that's what I meant when saying about 'cleaning' - going through > 10,000 places and remove/comment stuff is tough). | |
| Dec 27, 2018 at 20:54 | comment | added | Jochen | The beta feature seems nice. I'd still need to catch the permission error as is the case now, but it will be nice not to have to list all the fields in the check, and then again in the query, so it will save a few lines and possible errors. Looking forward to it's general release, although I'm note sure what you mean by needing to clean it up. I'd likely leave existing code as is, not least because it passes the security review. | |
| Dec 27, 2018 at 17:12 | comment | added | Jochen | The referenced class takes an Objectype and a list of fields to either just check rights, returning a boolean, or asserting rights, raising a catchable exception. We query only for the fields necessary for the mechanisms to work, and, like I said, redirect to an error page if the rights aren't there, so it's just a few lines of code. | |
| Dec 27, 2018 at 14:57 | comment | added | wesaw | It doesn't matter if you are using third party solution or your own one to check for CRUD. The same problem remains. You need to go over all your code base & apply these checkings to each query and field individually. That's a lot of routine and error-prone work to do. Moreover it's hard to force devs to follow this practice for all on-going features. Also SF has plans to implement this CRUD enforcing as a part of the platform (Beta in Spring 19, releasenotes.docs.salesforce.com/en-us/spring19/release-notes/…), so you would need to clean it up. | |
| Dec 26, 2018 at 16:44 | comment | added | Adrian Larson♦ |
That recommendation seems off base, as AssertException is not catchable. Not sure why you got a downvote, but that may be part of the reason.
|
|
| Dec 26, 2018 at 16:34 | history | answered | Jochen | CC BY-SA 4.0 |