Hot answers tagged

32

Actually, this problem is due to the "aggressive" caching setting in LEX. Go to Setup Home > Security > Session Settings. Uncheck the option: Enable secure and persistent browser caching to improve performance. That should make it such that only a single page reload gives you new data/settings/etc.


13

Many fields cannot be changed once populated, such as Audit Fields. Run this script: for (SObjectField field : SObjectType.Account.fields.getMap().values()) { DescribeFieldResult describe = field.getDescribe(); if (describe.isCreateable() != describe.isUpdateable()) { system.debug(field); } } You should see something like: ...


12

You could write a helper method for this type of functionality: public Object flsGet(SObject record, SObjectField field) { return !field.getDescribe().isAccessible() ? null : record.get(field); } With this reusable method, you can now just one-line the check: Contact someRecord = [SELECT Name FROM Contact LIMIT 1]; system.debug(flsGet(someRecord, ...


9

Generally, code you've written is already CRUD- and FLS-safe, as long as you follow the basic guidelines regarding Visualforce elements (e.g. check FLS when not using apex:inputField, etc). You can always check FLS and CRUD in Apex Classes, Triggers, Batches, and Utility classes. FLS is almost never relevant in your code-- you generally want to perform ...


7

You don't need to check every field that you query. The issue really boils down to who manages security for the field -- your app or the admin. With standard objects, the answer is always the admin. With custom objects, it depends on whether the field is user visible and is used by users or whether it is internal and used only by your app. Things like wizard ...


7

To disable the setting mentioned in Greg's answer for scratch orgs, disable S1EncryptedStoragePref2 in your project scratch def JSON: config/project-scratch-def.json { "orgName": "My Scratch Org", "edition": "Developer", "orgPreferences": { "enabled": [ "S1DesktopEnabled" ], "disabled": [ "...


6

Please refer to this knowledge article. Basically you just need to add some checks like if (!Schema.sObjectType.Contact.fields.Name.isAccessible()){ return ''; } or if (!Schema.sObjectType.Contact.fields.Name.isUpdateable()){ return null; } For dynamic check you could use Describe functionality. Basically you need to use several methods ...


6

You could do something like: ((sObject)Type.forName('Account').newInstance()).getSObjectType().getDescribe().isAccessible(); Or you could do a global describe and get the values from the returned map Map<String,Schema.SObjectType> gd = Schema.getGlobalDescribe(); But you at least need to have the String of the Object name. If you don't at least ...


6

To help others who end up here, my response as an answer: From what you posted, looks like a false positive - so I would document it in review. Here is a link to a recent update from the SR team about how to document your false positives As much as anything, the team is looking for you to show awareness of implementing security on the platform, so if you ...


6

There are a few different ways to attack this problem, but the most common is to create a user with permissions, and then use System.runAs to execute your tests. I normally grant permissions to my packages via permset and not profiles, so I create a user, give it a permission set that I created, and then run the tests. That way I don't depend on the admin ...


6

As stated in the SOAP API Documentation FieldPermissions : Represents the enabled field permissions for the parent PermissionSet. This object is available in API version 24.0 and later. So when querying the FieldPermissions object you'll only get the enabled permissions Possible solution 1- You should query the list of all fields of an SObject with ...


5

Since Winter 20 release, we have Security.stripInaccessible() method which strips the fields that the current user can’t access from query and subquery results. Since Spring 20 release Security.stripInaccessible() method is Generally Available. You can use it to remove inaccessible fields from sObjects before a DML operation to avoid exceptions. You can ...


5

without sharing will not reinforce SFDC field level access and visibility, so you will be running your class on system context. In system context, Apex code has access to all objects and fields— object permissions, field-level security, sharing rules aren’t applied for the current user. This is to ensure that code won’t fail to run because of ...


5

Yes the CRUD/FLS are also important on the packaged objects .The decision to assign the permission set or not should be left with the org administrator and not something the package vendor can restrict or technically impose on them .So the CRUD/FLS checks are still important on the packaged objects and your apex code should impose CRUD/FLS checks .


5

The best option today I think is to largely avoid CRUD & FLS and enforce security via custom permissions aligned with your business processes but that is not really answering your question. Part of the difficulty here is first understanding where to perform CRUD & FLS checks. For me the best answer to that is on service entry since it allows callers ...


5

As mentioned by @benahm, SOQL on FieldPermissions retrieves only enabled field permissions for the permission set. Furthermore, as per chapter "Special Properties for Field Permissions" in documentation here, fields that are always readable and/or writable, don’t return a FieldPermissions record. Note that getDescribe methods can also be accessed via REST ...


4

Don't know of any tools that do this, but I'd do one of the following: Update a single profile via the UI to match the appropriate FLS, and then update the other profiles within the force.com IDE. i.e. copy and paste the XML from one profile on to the others. Be careful that you don't override any other values you care about. You'd probably want to do a ...


4

Platform Encryption will go further than just preventing the users from seeing data, it will also encrypt the fields at the database level. For example, you can't even issue a SoQL query doing an "Order By XXX" if that field is encrypted. Also, PE lets you encrypt fields not subject to FLS (Account and Contact name, for example). In those cases, users will ...


4

The only reasonable method I know of is to use a try-catch block: try { record.put(someField, someValue); } catch(SObjectException e) { // Field could not be written } Unfortunately, this is an expensive construct (~30ms per failed access), so you might want to at least pre-validate that it is !(isCalculated() || isAutoNumber()).


4

Checkmarx is not "useless," and, in fact, is very good at what it does. However, that's not to say that false positives are not possible. It can make mistakes. However, whenever you get a flag like this, you should check and see if it is a legitimate problem or not. If it is a false positive, document it and go on. Flags are not automatic rejections for ...


4

You cannot update Auto Number fields, by nature. If you want to have a Name field that includes an Auto Number as well as some text derived from other fields on the record, you should add a non-Name Auto Number field to your object. You can then use Process Builder to populate the Name field with a formula incorporating that Auto Number field along with ...


4

The most voted advice will get you failed at the security review. End-users rely on CRUD/FLS configurable from UI Setup, and they will get quite surprised that your app does not respect the standard platform access restriction functionality. My advice is to check for CRUD/FLS inline, no libraries, as close as possible to the code that accesses the object, i....


4

The answer was given by Chris Peterson (PM of Apex) and MVP Daniel Ballinger during Dreamforce '19 in the session "Reducing the Cost of Enforcing CRUD and FLS in the ESAPI". And the answer is: By using the new Force.com ESAPI implementation from Github With Spring' 20 the Security.stripInaccessible() is GA. Peterson and Ballinger rewrote this Salesforce-...


4

Update How to get Object Describe in Lightning Web Component. You can get that using the uiObjectInfoApi module. import { LightningElement, wire } from 'lwc'; import { getObjectInfo } from 'lightning/uiObjectInfoApi'; import ACCOUNT_OBJECT from '@salesforce/schema/Account'; export default class FieldDescribeDemo extends LightningElement { @wire(...


3

After our meeting with a rep who walked us through Shield in more detail, he said basically there are two reasons to use Platform Encryption: You are worried someone is going to physically steal a hard drive from Salesforce's data centers. The government (or your internal compliance team) tells you that you have to. It sounds like HIPAA actually doesn't ...


3

The main advantage of Platform Encryption versus Classic Encrypted Custom Fields is: Transparency for business critical Platform features, such as search, workflow, and validation rules You'd have to invistigate requirements for private health records storage, as FLS would not be an option in case of: Privacy policies, regulatory requirements, and ...


3

Yes, you can migrate FLS using the Eclipse IDE or Metadata API. Basically, create a "package.xml" that contains both the objects to migrate permissions for and the profiles to export in a single file, then perform the retrieve call. The profiles directory will include one XML file per exported profile that will include both the object and field level ...


3

So Yes its of course possible you can do it in two ways (which essentialy are the same) Schema.sObjectType.Account.isUpdateable() and Account.sObjectType.getDescribe().isUpdateable() if (!Schema.sObjectType.Account.fields.Name.isUpdateable() && !Schema.sObjectType.Account.fields.BillingStreet.isUpdateable() ){ update acc; } That ...


3

You cannot change field level security by a workflow. However, you could do something like this: Create a new record type for your object Create a new page layout (on which you show this specific field) and assign it to the record type Create a workflow rule based on your criteria + field update that changes the record type


3

All security-related methods, such as UserRecordAccess and the describe calls, will always return the user's real permissions. All that "without sharing" does is turns off the permission and sharing table checks when querying, updating, or deleting records. It is strongly recommended by salesforce.com that developers check for a user's permission to fields, ...


Only top voted, non community-wiki answers of a minimum length are eligible