Хранение настроек плагинов

[ZooY]

Коллеги, поделитесь опытом, кто как реализует хранение настроек плагинов. Я имею в виду, например, параметры доступа к внешним ресурсам, вроде строк подключения к БД и пр.

Для себя выделил несколько возможных вариантов, все со своими плюсами и минусами.

Да и кстати, речь идет об on-premises (с онлайном, понятно будут другие варианты).

[Артем Enot Грунин]

Однозначно не рекомендую варианты с файлом и внешним сервисом. Файл нельзя достать из песочницы + возникают дополнительные сложности с мульти-тенант развертыванием (несколько баз организации на одном сервере) и переносом решения. Кроме того, будет серьезная просадка производительности за счет чтения из файла. Для плагинов это не столь критично, так как каждый инстанс создается один раз, а вот для рабочих процессов ситуация будет однозначно хуже.

MS использует сущности с атрибутами (отдельные объекты под группу настроек). Перенос рекомендуется делать через Package Deployer / Configaration Migration.

Не совсем понятно, почему Action не защищен от пользователей? C лукапами, пожалуй, тоже нет проблем. Вцелом, я рассматривую Action как альтернативу сущностям, но они создают определенные сложности при обновлении:

• Если вынести их в отдельное решение - вы создаете зависимость базового решения от дочернего.
• Появление новой настройки вынуждает вас обновить решение и затереть настройки текущего инстанса
• Не очень подходит для CI/CD сценариев

В конечном итоге, я, в большей степени склоняюсь к сущностям. Настройки - это больше данные, чем метаданные, так что им не место в решении. Плюс больше гибкость с точки зрения разделения доступа (разделение привилегий, FLS).

[ZooY]

Цитата:

Сообщение от Артем Enot Грунин

Не совсем понятно, почему Action не защищен от пользователей?

Потому что вызвать его может любой пользователь. Защита основана только на том, что пользователь не знает ключей настроек.

По поводу сущностей, есть одна проблема. Давай всем пользователям доступ к сущности настроек - это значит любой пользователь через расширенный поиск или импорт сможет все посмотреть.
Если права на чтение будут только у админа, значит для каждого шага плагина, который использует настройки нужно указывать этого пользователя в Run in user's context, чтобы от имени этого пользователя можно было обратиться к настройкам. А значение этого поля при переносе со среды на среду может слетать.

[a33ik]

Цитата:

Сообщение от ZooY

Потому что вызвать его может любой пользователь. Защита основана только на том, что пользователь не знает ключей настроек.

По поводу сущностей, есть одна проблема. Давай всем пользователям доступ к сущности настроек - это значит любой пользователь через расширенный поиск или импорт сможет все посмотреть.
Если права на чтение будут только у админа, значит для каждого шага плагина, который использует настройки нужно указывать этого пользователя в Run in user's context, чтобы от имени этого пользователя можно было обратиться к настройкам. А значение этого поля при переносе со среды на среду может слетать.

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

[ZooY]

Цитата:

Сообщение от a33ik

При инстанциации сервиса в коде плагина у вас есть 2 варианта - передавать гуид пользователя или нет. Если передаете - то сервис инстанциируется с правами пользователя. А вот если в метод не передано ничего у вас по сути сервис с админскими правами - доступайтесь до чего надо.

Да, но нет... %)
Если пользователь не указан явно, то подставляется Calling User, т.е. в контексте плагина свойства UserId и InitiatingUserId равны и ссылаются на конченого пользователя (прав на чтение настроек у которого нет). Это логично с точки зрения безопасности, но создает проблему в случае с настройками.

В принципе, нет проблемы указать привилегированного пользователя при настройках шага плагина, но проблема в том, что порой эта настройка не переноситься при переносе плагина решением. Возможно дело в каких то отличиях в именовании пользователя и возможно этот момент можно отладить.

[a33ik]

Читаем внимательно это - https://docs.microsoft.com/en-us/dot...s-general-ce-9

А именно, цитирую:

When called in a plug-in, a null value indicates the SYSTEM user

Т.е. ничего указывать и не надо. Просто специальным образом используйте код.

[Артем Enot Грунин]

Вы можете использовать пользователя SYSTEM он один на все CRM в мире.



p.s. Альтернатива, как всегда, утки - для этого и существует secure config. Есть готовые скрипты PowerShell чтобы можно было править их автоматизированно: https://github.com/WaelHamze/xrm-ci-framework

[ZooY]

У меня какой то взрыв мозга... Попытался проверить поведение Organization Service в плагине при разных идентификаторах пользователя...
Попробовал получать экземпляр сервиса с разными идентификаторами пользователей, для каждого экземпляра выполнял WhoAmIRequest и надеялся получить разных пользователей на выходе.
Собственно, вот код плагина:

public class GetUsers : IPlugin
{
    public void Execute(IServiceProvider serviceProvider)
    {
        var context = (IPluginExecutionContext)serviceProvider.GetService(typeof(IPluginExecutionContext));
        var factory = (IOrganizationServiceFactory)serviceProvider.GetService(typeof(IOrganizationServiceFactory));

        var result = "";

        var service1 = factory.CreateOrganizationService(null);
        result += $"null = {GetUserInfo(service1)}";

        var service2 = factory.CreateOrganizationService(Guid.Empty);
        result += $"Guid.Empty ({Guid.Empty}) = {GetUserInfo(service2)}";

        var service3 = factory.CreateOrganizationService(context.UserId);
        result += $"UserId ({context.UserId}) = {GetUserInfo(service3)}";

        var service4 = factory.CreateOrganizationService(context.InitiatingUserId);
        result += $"InitiatingUserId ({context.InitiatingUserId}) = {GetUserInfo(service4)}";

        throw new InvalidPluginExecutionException(result);
    }

    private static string GetUserInfo(IOrganizationService service)
    {
        var request = new WhoAmIRequest();
        var response = (WhoAmIResponse)service.Execute(request);
        var userId = response.UserId;
        var user = service.Retrieve("systemuser", userId, new ColumnSet("fullname"));
        var data = $"{userId} | {user.GetAttributeValue<string>("fullname")}{Environment.NewLine}";
        return data;
    }
}

А вот результат:

null = 34248a5f-bf3e-4f3c-95c2-882424d25d37 | SYSTEM
Guid.Empty (00000000-0000-0000-0000-000000000000) = 34248a5f-bf3e-4f3c-95c2-882424d25d37 | SYSTEM
InitiatingUserId (c69c88fb-4e41-e811-a214-83daa2756e35) = 34248a5f-bf3e-4f3c-95c2-882424d25d37 | SYSTEM
UserId (e73922d1-d7ec-e811-a224-ddda898a939f) = 34248a5f-bf3e-4f3c-95c2-882424d25d37 | SYSTEM

Т.е. в независимости от того, от чьего имени создается экземпляр сервиса, WhoAmIRequest возвращает одного и того же пользователя.
Как так?

[a33ik]

Покажите, пожалуйста, настройку шага из Plugin Registration Tool-а.

[ZooY]

Вот...

[ZooY]

Еще попробовал посоздовать записи от имени разных сервисов... Результат - все записи созданы от имени SYSTEM. Попробовал на двух системах - 2016 и 365

[a33ik]

Попробуйте сменить "Run in User's Context" на "Calling User".

[ZooY]

Попробовал. Ничего не поменялось (кроме того что UserId и InitiatingUserId стали ровны).

[Артем Enot Грунин]

Я наблюдал похожее, когда службы CRM (в частности, application pool) были запущены под учетными записями пользователей. Вы точно ничего не запустили под Натальей Вороновой?

[ZooY]

Цитата:

Сообщение от Артем Enot Грунин

Я наблюдал похожее, когда службы CRM (в частности, application pool) были запущены под учетными записями пользователей. Вы точно ничего не запустили под Натальей Вороновой?

CRM работает под сервисными учетками. Указанный пользователь выбран случайным образом из списка пользователей - это рядовой пользователь.
Кроме того я проверял на 2 системах вообще в двух разных компаниях. Даже способ развертывания и версии CRM отличаются. Картина одинаковая - все что делает сервис в плагине делается от имени SYSTEM.

Может кто-то у себя сможет проверить, код плагина в посте выше... Сравним результаты...

[Konstantin Katsovich]

Попробуйте вот так, без WhoAmIRequest

result += string.Format("Caller User Id = {0}",((OrganizationServiceProxy)factory.CreateOrganizationService(context.UserId)).CallerId);

result += string.Format("User System Id = {0}", ((OrganizationServiceProxy)factory.CreateOrganizationService(null)).CallerId);

[ZooY]

Цитата:

Сообщение от Konstantin Katsovich

Попробуйте вот так, без WhoAmIRequest

У меня задача не ID верные получить, а убедиться, что имперсонализация в сервисе работает и сервис выполняет действия от имени указанных пользователей. А он почему то этого не делает.

[Konstantin Katsovich]

Цитата:

Сообщение от ZooY

У меня задача не ID верные получить, а убедиться, что имперсонализация в сервисе работает и сервис выполняет действия от имени указанных пользователей. А он почему то этого не делает.

У меня Ваш код тоже возвращает один и тот же гуид
Использовать из плагина WhoAmIRequest нет смысле, он всегда вернет SYSTEM
СРМ же работает на основании CallerId
поэтому я и хотел что бы ва проверили

Я такой трик с SYSTEM использую очень часто и все работает в соответствии с правами эзера, систем видит все, остальные юзеры только то что положено