AppExchange package security review

Привет сообщество,

есть у кого опыт с успешным прохождением Security review с такой вот штукой:
- Sharing Violation

Смысл задачи - заказчик очень хочет чтобы контакты и related records синхронизировались с внешним сервисом. Даже тем пользователем, который умеет только читать контакт.

К примеру имеем OWD: Contact - public read, Related records - Public Read/Write
Utils class without sharing с кучей DML - решает задачу синхронизации, но первый раунд security team этот Without sharing не одобрила. Согласно некоторым статьям - такое возможно, но надо знать волшебное слово: https://developer.salesforce.com/page/Without_Sharing.

Если можно что-то с этим сделать без перелопачивания пакета - будет замечательно

С уважением

Привет сообщество,

есть у кого опыт с успешным прохождением Security review с такой вот штукой:
  - Sharing Violation

Смысл задачи - заказчик очень хочет чтобы контакты и related records синхронизировались с внешним сервисом. Даже тем пользователем, который умеет только читать контакт.

К примеру имеем OWD: Contact - public read, Related records - Public Read/Write
Utils class without sharing с кучей DML - решает задачу синхронизации, но первый раунд security team этот Without sharing не одобрила. Согласно некоторым статьям - такое возможно, но  надо знать волшебное слово: https://developer.salesforce.com/page/Without_Sharing.  

Если можно что-то с этим сделать без перелопачивания пакета - будет замечательно

С уважением

А почему класс without sharing если контакты и related records "public read"/"public read/write"?
Если поменять without sharing на with sharing что изменится?

camamber

А почему класс without sharing если контакты и related records "public read"/"public read/write"?
Если поменять without sharing на with sharing что изменится?

Нужно подготовить False Positive Doc с обьяснением/обоснованием почему вам нужно иметь without sharing для Utility класса.
Тут есть один пример, но вообще мы и по другому оформляли. Главное чтобы SF review team это поняли. В самом классе тоже не помешает иметь коммент с обьяснением. Как правило если это нужно для имплементации бизнесс логики вашего продукта, то они (review team) идут на встречу.
https://developer.salesforce.com/docs/atlas.en-us.packagingGuide.meta/packagingGuide/security_review_example_checkmarx_scan.htm

Rustam Muhametdinov

Нужно подготовить False Positive Doc с обьяснением/обоснованием почему вам нужно иметь without sharing для Utility класса.
Тут есть один пример, но вообще мы и по другому оформляли. Главное чтобы SF review team это поняли. В самом классе тоже не помешает иметь коммент с обьяснением. Как правило если это нужно для имплементации бизнесс логики вашего продукта, то они (review team) идут на встречу.
https://developer.salesforce.com/docs/atlas.en-us.packagingGuide.meta/packagingGuide/security_review_example_checkmarx_scan.htm

Смысл задачи - заказчик очень хочет чтобы контакты и related records синхронизировались с внешним сервисом. Даже тем пользователем, который умеет только читать контакт.
К примеру имеем OWD: Contact - public read, Related records - Public Read/Write

Вообще как бы Security Team правы в своем решении. Не кажется ли что требования заказчика противоречат сами себе? Либо делайте Public Read/Write для Contact. Либо выносите задачи синхронизации в другой контекст (асинхронный).

Не стоит надеяться на удачу что security team пойдет к вам на встречу. Думаю для этого надо минимум обладать статусом какого-нибудь Salesforce Partner чтобы вести какой-то продуктивный диалог. Проще и быстрее поменять код.

Dmitry Shnyrev

[quote="VV"]Смысл задачи - заказчик очень хочет чтобы контакты и related records синхронизировались с внешним сервисом. Даже тем пользователем, который умеет только читать контакт.

К примеру имеем OWD: Contact - public read, Related records - Public Read/Write[/quote]

Вообще как бы Security Team правы в своем решении. Не кажется ли что требования заказчика противоречат сами себе? Либо делайте Public Read/Write для Contact. Либо выносите задачи синхронизации в другой контекст (асинхронный).

Не стоит надеяться на удачу что security team пойдет к вам на встречу. Думаю для этого надо минимум обладать статусом какого-нибудь Salesforce Partner чтобы вести какой-то продуктивный диалог. Проще и быстрее поменять код.

Спасибо всем за ответы.

Camamber, При изменении класса на with sharing - обычный пользователь (не оунер, и не админ, и не менеджер) не сможет синкнуть контакт. Вот с таким exception:
Update failed. First exception on row 0 with id 003...; first error: INSUFFICIENT_ACCESS_OR_READONLY, insufficient access rights on object id: []

Rustam Muhametdinov, False Positive Doc - Это как раз и есть первая мысль, убедить security team. Интересно само содержание это доки, как доказать команде, что это дизайн такой Спасибо за пример.

Dmitry, лимиты на асинхронный Apex - они неплохие и, наверное, очень сложно воткнуться в число 250 000+, даже если каждую минуту жать кнопку Sync на лейауте, так что вариант. Я скорее думала о Platform events, как о решении, но учитывая контекст проекта, False positive doc, все же пока первый шаг.

Спасибо всем за ответы. 

Camamber, При изменении класса на with sharing - обычный пользователь (не оунер, и не админ, и не менеджер) не сможет синкнуть контакт. Вот с таким exception:
Update failed. First exception on row 0 with id 003...; first error: INSUFFICIENT_ACCESS_OR_READONLY, insufficient access rights on object id: []   

Rustam Muhametdinov, False Positive Doc - Это как раз и есть первая мысль, убедить security team. Интересно само содержание это доки, как доказать команде, что это дизайн такой :) Спасибо за пример.

Dmitry, лимиты на асинхронный Apex - они неплохие и, наверное, очень сложно воткнуться в число 250 000+, даже если каждую минуту жать кнопку Sync на лейауте, так что вариант. Я скорее думала о Platform events, как о решении, но учитывая контекст проекта, False positive doc, все же пока первый шаг.

Dmitry, лимиты на асинхронный Apex - они неплохие и, наверное, очень сложно воткнуться в число 250 000+, даже если каждую минуту жать кнопку Sync на лейауте, так что вариант. Я скорее думала о Platform events, как о решении, но учитывая контекст проекта, False positive doc, все же пока первый шаг.

Под понятием "асинхронный контекст" я имел в виде не future/queueable или прочие async вызовы кода про которые лимит 250К. Я скорее имел в виду отдельный поток для синхронизации который не зависит от пользователя.
Это может быть как упомянутые Platform events, так и Scheduler и очередь заданий на синк, а также другие экзотические способы, которые позволяют стартануть код синхронизации в контексте с повышенными привилегиями. Но это все подразумевает изменение бизнес логики проекта и дополнительное кодирование

Если будет не сложно то можешь держать нас в курсе событий по данному вопросу? Удастся протолкнуть текущий вариант через security review или придется менять код. Очень интересно!

Dmitry Shnyrev

[quote="VV"]Dmitry, лимиты на асинхронный Apex - они неплохие и, наверное, очень сложно воткнуться в число 250 000+, даже если каждую минуту жать кнопку Sync на лейауте, так что вариант. Я скорее думала о Platform events, как о решении, но учитывая контекст проекта, False positive doc, все же пока первый шаг.[/quote]
Под понятием "асинхронный контекст" я имел в виде не future/queueable или прочие async вызовы кода про которые лимит 250К. Я скорее имел в виду отдельный поток для синхронизации который не зависит от пользователя.
Это может быть как упомянутые Platform events, так и Scheduler и очередь заданий на синк, а также другие экзотические способы, которые позволяют стартануть код синхронизации в контексте с повышенными привилегиями. Но это все подразумевает изменение бизнес логики проекта и дополнительное кодирование :) . 

Если будет не сложно то можешь держать нас в курсе событий по данному вопросу? Удастся протолкнуть текущий вариант через security review или придется менять код. Очень интересно!