Кеширует ли менеджер ролей данные для поставщика пользовательских ролей, и можно ли очистить этот кеш?

Question

Я использую пользовательский поставщик ролей, который для упрощения получает объект person из базы данных, используя EF в проекте .net 4 MVC, и распределяет роли пользователей на основе некоторых правил вокруг этого (и других запросов).

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

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

Я гарантировал, что роли не кэшируются в файле cookie, установив cacheRolesInCookie=false, на что, как кажется, указывает большинство справок, иПредположим, что в диспетчере ролей есть встроенный кеш сеанса.

Я изменил EF-запрос, который возвращает объект person для включения метки времени как части запроса.Я могу видеть через профилировщик, что запрос фактически вызывается, и отметка времени меняется каждый раз, но мой сеанс отладки показывает устаревшие данные из предыдущего состояния для элемента person.Существуют и другие части сайта, которые отображают данные из таблицы Person, которые показывают текущее состояние.

Я не совсем понимаю, как отладчик должен вести себя на кэшированных данных.Я не понимаю, почему запрос EF вообще сработает, если это проблема с кешем, но данные о персонале определенно показывают состояние в соответствии с первым запуском, а не в соответствии с текущим состоянием строки таблицы.

Я чувствую, что упускаю что-то очевидное.Кеширует ли Role Manager данные в сеансе?

Answer 1

Ответ действительно зависит от архитектуры вашего приложения.У меня недавно была эта проблема, и я также обвинял кэш Role Manager.Оказывается, это было управление контекстом сущности в моем уровне доступа к данным.Я управлял своим Entity Context и сохранял контекст для каждого запроса, как это обычно рекомендуется.Однако проблема заключалась в том, что контекст устанавливался дважды из-за несвязанного дефекта, и поэтому контекст поставщика ролей всегда отличался от остальной части приложения и устанавливался только один раз (так как поставщик ролей создается при запуске приложения, а непо запросу).

Я бы порекомендовал посмотреть, как вы храните контексты данных и проследить, чтобы увидеть, как они хранятся по отношению к вашему Role Manager по сравнению с остальной частью приложения.Убедитесь, что вы действительно используете один контекст для запроса .

Answer 2

У меня есть ответ на вопрос «Можно ли очистить этот кеш?»

Да, вы можете очистить кэш диспетчера ролей.

(примечание: этот метод отличается от удаления файла cookie кэша ролей и позволяет очистить кэш во время запроса).

Диспетчер ролей будет кэшировать роли для текущего пользователя в HttpContext.Current.User после первого вызова поставщика ролей для получения ролей.

Этот кеш будет использоваться при последующих проверках ролей на протяжении всего запроса, и ваш пользовательский поставщик ролей не будет вызываться.

Однако вы можете заставить Role Manager снова вызывать вашего поставщика ролей (и эффективно перехватывать роли из источника данных), приведя текущего пользователя к RolePrincipal и затем вызвав SetDirty ()

Например:

RolePrincipal currentUser = HttpContext.Current.User as RolePrincipal;
currentUser.SetDirty();

См. Документация MS по методу RolePrincipal.SetDirty