Стратегии кэширования ролей в ASP.NET MVC

Question

У нас есть приложение ASP.NET MVC, для которого мы разработали наш собственный класс RoleProvider. Без кэширования он будет обращаться к хранилищу данных для каждого запроса - плохо. Единственный вариант кэширования, который мы можем найти, - это (в web.config) файлы cookie, хранящиеся на клиентских компьютерах. Мои два вопроса:

1. Безопасно ли это (даже с включенным шифрованием)?
2. Будет ли информация о файлах cookie передаваться при каждом веб-запросе, что может замедлять работу приложения, а не обращаться к хранилищу данных каждый раз?

У кого-нибудь есть альтернативный маршрут? Я так понимаю, что кэширование этой информации в сеансе тоже плохо?

Answer 1

Если вы разработали свой собственный класс RoleProvider, вы можете выполнить собственное кэширование данных, например, используя кеш ASP.NET. Это более гибкий подход, чем использование Session в качестве кэша, поскольку он будет работать даже на страницах, для которых состояние сеанса не включено.

Я не согласен с комментарием Уайета Барнетта:

Недостаток использования сессии ... тот факт, что хранилище сеансов очень нарушают и не особо надежно

Нормально, чтобы кеш (будь то Session, ASP.NET Cache или что-то еще) был изменчивым - вам просто нужно заполнить его, когда потребуется.

Чтобы ответить на ваши вопросы:

1. Это так же безопасно, как шифрование, используемое для шифрования куки. Если вы полагаетесь на FormsAuthentication, он должен быть не менее безопасным, чем билет для проверки подлинности с помощью форм.

2. Файл cookie будет передаваться при каждом запросе. Таким образом, это может привести к снижению производительности, если пользователи могут иметь очень большое количество ролей, и может превысить максимальный размер файла cookie, поддерживаемый браузером.

Answer 2

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

Answer 3

Хотя идея о том, что запросы к БД по каждому запросу неэффективны, верна, но помните, что производительность SELECT для правильно проиндексированных таблиц в современных БД является невероятно быстрой, поэтому сначала я бы предпринял некоторые измерения, чтобы убедиться, что этот сценарий действительно негативно влияет на производительность.по сравнению с теоретически может негативно повлиять на производительность на более позднем этапе.

Недостатком использования Session является не столько накладные (минимальные) издержки, сколько тот факт, что хранилище Session очень нарушает и не особенно надежно.Например, вы можете легко потерять сеанс и при этом иметь зарегистрированного пользователя.

Тем не менее, хороший способ посередине - кэшировать роли пользователя для каждого запроса с использованием коллекции HttpContext.Items.Это ограничит один SELECT на запрос, что, вероятно, является достаточно эффективным (см. Выше измерение), избегая при этом других проблем с хранением - таких как жирный, небезопасный файл cookie или какое-либо довольно серьезное нарушение решения на основе сеанса.