存储架构

Salesforce Object Level and Field Level Security Architecture

微信扫一扫,分享到朋友圈

Salesforce Object Level and Field Level Security Architecture
0

3. DML – Unit of Work

This is not currently implemented to check the following:

1. Insert

if (enforceOLS){
       fflib_SecurityUtils.checkObjectIsInsertable(sObjectType);
  }

2. Update

if (enforceOLS){
       fflib_SecurityUtils.checkObjectIsUpdateable(sObjectType);
  }


3. Delete 

if (enforceOLS){
     fflib_SecurityUtils.checkObjectIsDeletable(m_sObjectTypes[objectIdx--]);
  }

Disadvantages of OLS and FLS implemented across your app

OLS– this is a check that is done to see if the user profile has access to do CRUD on the specific object. If this check is not done and user tries to do any of the CRUD operations it will just result in a Salesforce error. Doing this check on an object level is not too big of an overhead. If these checks are not done, Permission errors will be thrown as the profile does not have the correct permission.

FLS– this is not recommended as we have to iterate through every field of the object and check if the user has the privileges to read/update/insert/delete to that field. This slows down operations down drastically and only needs to be used in a few uses cases.

Possible solutions run security checks on app

Have a way to enable both OLS and FLS in your code then run through all your test and see if any break. If the break GREAT fix your Object Settings/FLS so that they work. When running in Production have a way to disable this as it may/will slow down your operations/services.

阅读原文...


微信扫一扫,分享到朋友圈

Salesforce Object Level and Field Level Security Architecture
0

Avatar

New $14 esp32 VGA/mouse/keyboard/VT100 computer capable of running micropython

上一篇

Book Review: Docker on Windows: From 101 to Production

下一篇

评论已经被关闭。

插入图片

热门分类

往期推荐

Salesforce Object Level and Field Level Security Architecture

长按储存图像,分享给朋友