Можно ли использовать ключ в сеансе для роли текущего пользователя? - PullRequest
2 голосов
/ 17 февраля 2010

Могу ли я просто использовать Session ["role"] = "theRole", или это было бы плохой практикой, поэтому я бы создал свой собственный атрибут авторизации, где я собираюсь посмотреть в Session

Ответы [ 6 ]

4 голосов
/ 17 февраля 2010

Как правило, в любое время, когда вы работаете с собственной безопасностью, в лучшем случае это сомнительно.Есть ли какая-то причина, по которой вы не можете использовать встроенный объект User и метод IsInRole для своего определения?

3 голосов
/ 17 февраля 2010

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

Вам не нужно реализовывать членство провайдера. Все, что вам нужно сделать, это установить HttpContext.User на пользовательский IPrincipal , и вы можете использовать User.IsInRole("role") и [AuthorizeAttribute(Roles="role")].

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

1 голос
/ 17 февраля 2010

Вместо создания новой переменной Session, как насчет использования существующего HttpContext.Current.User ? Это находится в пространстве имен System.Security.Principal.

У него есть массив ролей, которые вы можете заполнить, а затем проверить с помощью if (thisUser.IsInRole("admin")) ...

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

System.Web.Security.FormsIdentity id = new FormsIdentity(new FormsAuthenticationTicket("dok", false, 30));
        string[] roles = { "admin" };
        HttpContext.Current.User = new System.Security.Principal.GenericPrincipal(id, roles);
1 голос
/ 17 февраля 2010

Это неплохо, но хорошим принципом является использование объекта Principal и использование поставщика членства для ответа на ваши запросы о ролях.

0 голосов
/ 17 февраля 2010

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

0 голосов
/ 17 февраля 2010

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...