New answers tagged field-level-security
7
I am partial to stripInaccessible because WITH SECURITY ENFORCED because the queries throw an exception if any of the fields are not available to the user. I would not make it automatic to trigger execution, I would modify the triggers to pass this parameter. That will allow you to bypass FLS checks in other code that may need FLS bypassed (like an engine ...
0
For your VAccountTriggerHandler class, yes, you'll need to enforce CRUD/FLS checks (as well as sanitation and other protective measures) manually for security review purposes.
Consider using WITH SECURITY_ENFORCED in your SOQL for a quick catch-all CRUD/FLS fix, or consider .stripInaccessible(), both of which are going GA soon.
See (and do) the Develop ...
2
The Visualforce page has built-in measures to respect the CRUD/FLS settings of the logged-in user.
As the trailhead unit describes:
This table displays the object fields using standard object notation--{!p.Name}, {!p.Description__c}, {!p.Found__c}, {!p.Castle__r.Name}--so by default the platform enforces any CRUD and FLS restrictions. This is why, just ...
2
1 & 2 are addressed in documentation
In this example, the user doesn’t have permission to create the Probability field of an Opportunity.
List<Opportunity> opportunities = new List<Opportunity>{
new Opportunity(Name='Opportunity1'),
new Opportunity(Name='Opportunity2', Probability=95)
};
// Strip fields that are not creatable
...
Top 50 recent answers are included
