Показать сообщение отдельно
Старый 07.02.2019, 15:59   #5  
a33ik is offline
a33ik
Чайный пьяница
Аватар для a33ik
MCP
MCBMSS
Злыдни
Соотечественники
Most Valuable Professional
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
3,151 / 849 (35) +++++++
Регистрация: 02.07.2008
Адрес: Greenville, SC
Цитата:
Сообщение от ZooY Посмотреть сообщение
Потому что вызвать его может любой пользователь. Защита основана только на том, что пользователь не знает ключей настроек.

По поводу сущностей, есть одна проблема. Давай всем пользователям доступ к сущности настроек - это значит любой пользователь через расширенный поиск или импорт сможет все посмотреть.
Если права на чтение будут только у админа, значит для каждого шага плагина, который использует настройки нужно указывать этого пользователя в Run in user's context, чтобы от имени этого пользователя можно было обратиться к настройкам. А значение этого поля при переносе со среды на среду может слетать.
При инстанциации сервиса в коде плагина у вас есть 2 варианта - передавать гуид пользователя или нет. Если передаете - то сервис инстанциируется с правами пользователя. А вот если в метод не передано ничего у вас по сути сервис с админскими правами - доступайтесь до чего надо. Так что ваша "проблема" доступа к настроечной сущости решается именно таким образом:
1. Все настройки хранятся в кастономной сущности (одна запись и много полей или много записей типа пара ключ/значение - на ваше усмотрение).
2. У обычных пользователей нет прав на зачитку этих сущностей.
3. В коде плагинов при помощи подхода, указанного ранее, получаете доступ к настройкам вне зависимости от того, кто вызвал запуск плагина - простой юзер или юзер с доступом к настройкам.
__________________
Эмо разработчик, сначала пишу код, потом плачу над его несовершенством.

Подписывайтесь на мой блог, twitter и YouTube канал.
Пользуйтесь моим Ultimate Workflow Toolkit