Идентификация ASP.NET: почему свойства пользователя и утверждения?

Я действительно потерялся, пытаясь понять ASP.NET Identity 2.1.0 прямо сейчас, и мне нужно вернуться к основам, чтобы лучше понять, как работают файлы cookie и утверждения.

Основной вопрос связан с тем, что я не уверен, что понимаю, зачем Пользователю нужны свойства а также Заявки: не является ли Заявка просто ключом+значением+полномочием и, следовательно, мог бы использоваться для хранения Свойства (ключ+значение)? * В чем преимущество сохранения двух наборов свойств (кроме Typed get/sets в свойствах)? Является ли одно предназначено быть более преходящим, чем другое? * Это только для того, чтобы различать, что сериализуется и передается туда и обратно в Cookie (только утверждения, верно?)? * Говоря об этом... просто проверяю: это все претензии, которые передаются туда и обратно, будучи сериализованными в файле cookie, или это только их подмножество (например, ClaimTypes.Roles)?

Спасибо за помощь!


person stacker    schedule 14.10.2014    source источник


Ответы (1)


Все претензии к пользователю сериализуются в файл cookie. Не все свойства ApplicationUser сериализуются как утверждения. На самом деле, большинство свойств не сериализуются в утверждения (если только они специально не закодированы).

Вы путаете две концепции: утверждения являются частью ClaimsPrincipal : IPrincipal, доступной для каждого HTTP-запроса (если пользователь прошел проверку подлинности). ClaimsPrincipal создается из ApplicationUser, когда пользователь входит в систему и сериализуется в файл cookie.

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

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

Чтобы ответить на ваш последний вопрос: все претензии сериализуются и передаются в файле cookie. Так что не помещайте слишком много информации в файл cookie — они могут складываться, и вы будете передавать слишком много данных туда и обратно.

person trailmax    schedule 14.10.2014
comment
Спасибо, что заявили, что все претензии передаются туда и обратно... влияющие на размер. Спасибо за объяснение нюанса, что претензии могут быть уникальными для пользователя, например: факт, специфичный для используемого SSO, тогда как схема ApplicationUser одинакова для всех пользователей. Также думаю, что теперь я понимаю, что можно сразу использовать принципала для претензий (следовательно, ролей) - и для большего (например, размер обуви/пол/и т. д.) нужно выловить пользователя из БД, через UserManager. Но в чем преимущество двусторонней передачи реквизита в файле cookie, когда через 2 секунды я все равно попаду в БД для пользователя (некоторые БД присоединяются к чему-то еще)? - person stacker; 14.10.2014
comment
Я пытался задать вопрос: я знаю, что попадание в БД медленнее, чем в память, но не является ли файл cookie, содержащий роли, отправляемый с каждым GET для каждого изображения, css, html, js, требуется, возможно, будет хуже производительность ? Или это просто вопрос доверия - что MS провела свое исследование, и оказалось, что 15+ интернет-запросов (для страницы MVC) с несколько длинными (зашифрованными) значениями cookie по-прежнему быстрее, чем объект пользователя через интранет-соединение. Спасибо. Но я думаю, что это действительно должен быть другой вопрос ;-) - person stacker; 14.10.2014
comment
Чтобы ответить на ваш первый вопрос: данные, которые вы указываете в своих претензиях/куки-файлах, легко доступны вам, не обращаясь к БД. И если у вас интенсивно используемая система, это может сэкономить много db-вызовов при каждом запросе. Так что выбирайте мудро, что вы хотите положить в свое печенье. В нашем приложении я сохранил 3 дополнительных обращения к БД при каждом запросе, просто поместив пользовательские данные в файл cookie. - person trailmax; 14.10.2014
comment
По второму вопросу, если ваш куки такой большой - да, есть проблема. Но мои наблюдения показывают, что каждый байт, который вы помещаете в претензии, увеличивает размер вашего файла cookie в 1,1 раза. Таким образом, добавление имени человека почти ничего не будет стоить вам в файле cookie (20-30 дополнительных байтов), но сэкономит вам db-вызов при каждом запросе. И если вы находитесь в облаке, ваши db-вызовы могут быть дорогими из-за задержки в сети. - person trailmax; 14.10.2014
comment
А для статических объектов, таких как JS и CSS, вы должны поместить их в отдельный домен, для которого вы не устанавливаете cookie. - person trailmax; 14.10.2014
comment
И помните, преждевременная оптимизация — мать всех зол. Сначала выполните профилирование, а затем оптимизируйте узкие места. - person trailmax; 14.10.2014
comment
Спасибо. Полностью поймите, что использование домена без файлов cookie для JS/CSS/изображений является оптимальным решением. Хотя признаться никогда этим не занимался (мало трафика ;-( ) Но суть понял :-) - person stacker; 15.10.2014