Как отделить большие файлы cookie в asp.net Identity в меньшие, чтобы позволить много претензий?
-
21-12-2019 - |
Вопрос
Я работаю над прототипом разрешения на основе претензий для нашего приложения MVC. Мы используем идентичность ASP.NET для аутентификации.
Мы хотели бы иметь претензию на каждое действие контроллера, а затем предоставлять / забрать претензии пользователей, чтобы у нас был очень тонкий контроль над тем, кто может пойти туда.
Наше приложение уже имеет 800+ действий и продолжает расти. Я сделал небольшое тестовое приложение, чтобы увидеть, как это количество претензий может быть обработано. И столкнулся с проблемой: Печенье ограничено 4092 байтами .
и иметь большое количество претензий, увеличивает файл аутентификации идентичности. Около 600 претензий с короткими названиями / значениями (5 символов каждый) дают мне размеры cookie более 4k и пользователь с этим количеством претензий, просто не могу войти - cookie не может быть установлено в браузере.
и 600 претензий не является пределом для нашего приложения. Мы, вероятно, понадобится больше, чем это.
P.S. Если вам любопытно, вот мой Код для претензий "Profiler" Наряду с Остальная часть проекта .
p.p.s. Я знаю о последствиях эффективности крупных печений. Не беспокоиться об этом только сейчас.
<Сильное> Обновление В настоящее время нет вне поля для моего ответа. Но похоже, что я не единственный с этой проблемой. Microsoft.Owin
управляет Auth-cookie. И текущий исходный код для Owin.cookies имеет Chunkingcookiemanager Что присвоено по умолчанию в cookiageenticationmiddleware < / a>.
Плохой новости, что этот код очень свежий (был проверен 10 июля 2014 года, всего 20 дней). Он доступен посредством предварительного выпуска Nuget Microsoft.owin . Security.Cookies . Не уверен, что я хотел бы использовать RC2 на производственной площадке.
любой другой путь?
Решение 2
Я не решил прямой вопрос. Cookie слишком велико, и он останется большим с большим количеством или претензиями. OWIN v3.0 (в настоящее время в RC2 не готово к производству) имеет способ куски печенья в меньшие. Но большое печенье просто плохое. Поэтому я держу претензии только на стороне сервера.
У меня был Обсуждение на форуме Identity и нашел * */a> Вопрос, который полностью обращается к моим вопросам. Основывая вопрос, я сделал свое собственное решение и прозоидрил небольшое приложение MVC: https://github.com/ TrailMax / требования к требованиям .
Ядро решения находится в MVC Filter , который проверяет, доступны ли необходимые требования для пользователя.
Другие советы
Вы используете претензии неправильно.Претензии представляют собой идентичность пользователя, а не действия, которые им разрешено выполнять.Вы бежите проблемы, потому что вы лечите претензии как дома для пользовательских разрешений.Вы действительно должны найти способ отделить два в вашем приложении.
в моде MVC, это будет создавать пользовательский атрибут авторизации, получение идентификации пользователя из файла cookie и подтверждения того, что идентичность пользователя может выполнить некоторые действия.
См. Связанные вопросы ниже.
Ограничение доступа к записям.Разрешения на основе претензий хорошая идея
Вы должны использовать роль
[Authorize(Roles = "Admin, Role1")] public ActionResult Index(string id) {....} [Authorize(Roles = "Admin, Role2")] public ActionResult Index2(string id) {....} [Authorize(Roles = "Admin, Role1, Role3")] public ActionResult Index3(string id) {....}.