Как я реализую пользовательский Принципал и Идентификационные данные в ASP.NET MVC?

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

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

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

Каковы точные шаги, которые я должен рассмотреть, хочу ли я реализовать свой собственный Принципал или Идентификационные данные?

Что было бы самым простым, я мог сделать в этом сценарии (просто добавляют идентификатор и удерживают все значения по умолчанию на месте)? "Значения по умолчанию" включали бы поставщиков по умолчанию (членство, роли, и т.д.).

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

Было бы потрясающе смочь перейти к демонстрационному приложению ASP.NET MVC 2 (из шаблона Visual Studio 2010 года, например), сделать редактирования и иметь его работа.


Править: Я отредактировал вопрос лучше показать, что я в значительной степени потерян здесь, таким образом, я не могу суметь обойтись ответами слишком высокого уровня.

P.S.: мне кажется, что имеет больше смысла иметь идентификатор в Идентификационных данных вместо принципала, хотя я, в некотором смысле, заявил это прежде.

16
задан Community 23 May 2017 в 12:09
поделиться

2 ответа

На этот вопрос уже задавали и на него уже ответили: ASP.NET MVC - Установите настраиваемый IIdentity или IPrincipal

Но подведем итог ...

Создайте настраиваемый основной класс с дополнительными свойствами, которые вы хотите сохранить:

Public Class CustomPrincipal
    Inherits System.Security.Principal.GenericPrincipal

    Private _eyeColor As String
    Public ReadOnly Property EyeColor As String
        Get
            Return _eyeColor
        End Get
    End Property

    Public Sub New(id As System.Security.Principal.IIdentity, roles As String(), eyeColor As String)
        MyBase.New(id, roles)
        _eyeColor = eyeColor            
    End Sub

End Class

Измените global.asax Global.Application_AuthenticateRequest на используйте свой собственный принцип:

Protected Sub Application_AuthenticateRequest(ByVal sender As Object, ByVal e As System.EventArgs)
    ...
    Dim roles() As String = {"examplerole"}         
    Context.User = new CustomPrincipal(Context.User.Identity, roles, "green")
End Sub

Затем в другом месте вашего кода, если вы хотите обратиться к одному из этих свойств, сделайте следующее:

CType(My.User.CurrentPrincipal, CustomPrincipal).EyeColor
20
ответ дан 30 November 2019 в 22:01
поделиться

Вы не можете ожидать, что кто-то научит вас всему, чего вы не знаете о .NET, всего за несколько абзацев. Вы можете прочитать довольно хороший пример на MSDN http://msdn.microsoft.com/en-us/library/system.security.principal.genericprincipal.aspx и покопаться в классе и его производных в Reflector - в этом нет ничего особенного.

Роли - это просто строковый массив имен для вашего собственного использования в вашем приложении / сервере.

Сказав это, вам совсем не обязательно стремиться к точному производному GenericPrincipal. Ознакомьтесь с

HttpContext.Current.Items

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

HttpContext.Current.Items["TokenUser"] = new MyThinUser(anything,I,want,there);

, а затем все остальные в коде просто сделайте:

var user = HttpContext.Current.Items["TokenUser"] as MyThinUser;

и все готово.

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

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

Имейте в виду, что автогенерированные образцы в VS обычно ориентированы на определенный сценарий. Поэтому, если вы видите поставщиков SQL для управления пользователями, это не означает, что вам действительно нужно его использовать - вы все равно можете просто вызвать свой собственный sproc, чтобы получить то, что вам нужно, из своей собственной таблицы в SQL.

2
ответ дан 30 November 2019 в 22:01
поделиться
Другие вопросы по тегам:

Похожие вопросы: