Привет всем.
Поделитесь опытом кто проходил Security Review.
На что обращают внимание и какие вопросы задают в отношении
with sharing и without sharing модификаторов классов.
Понятно что по максимуму надо использовать with sharing, но что если надо использовать without scharing как его необходимо правильно использовать в пакете которые проходит проверку.
Так же, что означает если модификатор не будет указан вообще?
что-то я не могу уловить игру английских слов в этой предложении
If a class isn’t declared as either with or without sharing, the current sharing rules remain in effect. This means that the class doesn’t enforce sharing rules except if it acquires sharing rules from another class. For example, if the class is called by another class that has sharing enforced, then sharing is enforced for the called class.
Помогите с адекватным переводом.
Если нет модификатора, используется модификатор класса выше по стеку вызовов итд.
Это значит, что указывать with sharing и without sharing надо обязательно для всех классов, в противном случае эта опция будет установлена из вызывающего класса, и в результата with sharing и without sharing может быть разным в зависимости от того, откуда вызвали. Что почти всегда плохо. Также советую присмотреться к вложенным классам, они (как это не странно), не сохраняют модификатор outer класса.
Подробнее в документации
Еще можешь обратить внимание на SOQL Injection & XSS
Я так понимаю из описания что без модификатора класс на самом верху (контроллер) имеет тот же уровень доступа что и without sharing?
You have to explicitly set this keyword for the class because Apex code runs in 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.
Млин, почему я все это время был уверен что по умолчанию with sharing ставится.
И я правильно понимаю что сервис классы - например всякие Utils нужно оставлять без модификатора чтобы они наследовали модификатор доступа класса его вызывающего?
использую их редко (не надо ругать, знаю что динамические запросы универсальнее)Не знаю как сейчас, но думаю что вряд ли SF послабил эти правила, а год/два назад without sharing во время security review автоматически означал его провал, т.е. такой модификатор вообще не допускается. На счёт опускания модификатора вообще - не припомню, но не удивлюсь если это тоже как красная тряпка.
ilya, спасибо что поделился опытом.
Сейчас компания, где я пилю продукт активно занялась выходом на AppExcahge. Посмотрим что из этого получится. Но в продукте дофига где without sharing стоит. Вот я тоже думаю что будут проблемы.
На счет что был раньше красный свет - я бы сказал наверное что светло-красный потому что раньше тоже имел дело с продуктом, который выкатили в AppExchange и там были пара отдельных классов с модификатором without sharign (они как-то прямо так и назывались) куда сгрузили все методы которые требуют именно этого модификатора. В общем как-то пропихнули. Может как-то договаривались, не знаю, история умалчивает.
Раньше процедура выглядела так - надо было прогонять код через автоматический анализатор, который в случае каких-то подозрительных мест выдавал распечаточку, с приблизительным описаловом что ему не понравилось, а в случае если всё ОК, по-моему ничего не выдавал. А когда код отправлялся непосредственно на security review, одним из шагов надо было приложить вот этот сгенеренный файлик и давалась возможность приложить файлик с объяснениями типа - там ложное срабатывание анализатора, нам это надо для того-то и того-то, в общем можно было слёзно "мамой клянусь там всё надёжно" попросить и наверное могли пропустить :)До сих пор так. Только фришные пакеты сейчас не публикуются, по крайней мере из нашей страны :(
Да, помню про автоматический сканер - штука очень интересная и полезная. И правильно подмел что ее надо прикладывать к запросу на ручную проверку. Помню часть ошибок показал реальных, а часть ошибочных, причем это были известные баги сканера и на проверке на них не обратили внимание, сказали что все ок.
А вот что еще помню (из-за чего мой (заказчика) пакет не приняли в AppExchange) что придрались к сервису/сайту заказчика с API которого я интегрировался. Я как честный гражданин просканировал burp scanner (кстати его результаты тоже надо прикладывать если есть интеграция со сторонними системами) API и приложил к запросу. Оказывается этого недостаточно и надо просканировать ВЕСЬ сайт. Проблема оказалась в том что у заказчика login на сервис осуществлялся не по https. В общем так ничего и не доказали, а заказчик плюнул и забил на AppExchage.
Кстати помню случай еще бредовее!!! Публиковала компания пакет для интеграции с paypal. Так чуваки со стороны Salesforce натравили сканер на PayPal и выдали что нашли там ошибки (даже не связанные с API) и поэтому не могут пропустить пакет пока мы не пофиксим PayPal. Пришлось руководителю проекта доказывать что мы не можем "починить" PayPal.
Вот что вы думаете по этому поводу. Насколько правомерна такая "доебка" что сайт, API которого мы используем, имеет проблемы с безопасностью, которые никак не связаны с нашим SF приложением?
Я считаю что это тупо выкачивание денег с разработчиков, на регулярной основе. Они заявляют, что сканирование занимает минимум 2 недели и себестоимость его для них около 5.000 долларов. Серьезно ? Похоже что сам CEO салесфорса делает это ревью, а не кучка убогих индусов. Им еще и комментарии нужны. И если они что-то не понимают, возвращают тебе пакет обратно.
