Пользовательская аутентификация членства в Asp.net добавляет данные пользователя к данным пользователя с ролями

Question

Пользовательская аутентификация членства в Asp.net добавляет данные пользователя к данным пользователя с ролями

1

Я выполнил следующее руководство Forms-Authentication-and-Role-Based-Authorization, чтобы успешно выполнить аутентификацию и авторизацию членства. Я использовал сеансы для получения других пользовательских данных, таких как имя и фамилия. Однако сеанс может быть потерян, пока файл cookie auth все еще существует/действителен. Теперь я хочу иметь возможность добавлять данные пользователя в файл cookie, но не знаю, как это сделать. Думал добавить его в строку ролей и схватить его оттуда, но не уверен, что это за последствия. Я также видел эту ссылку Хранить данные в auth cookie, но не упоминает использование ролей.

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

Благодарю.

zulq 01 сен. 2014, в 18:37

Источник

Теги:

c#

asp.net

authentication

cookies

2 ответа

Ещё вопросы

Joe · Answer 1 · 2014-09-01T16-49-00.000Z

Вместо подхода, с которым вы связались, я бы создал пользовательский RoleProvider.

Что касается деталей пользователя, я бы оставил его отдельно от логики аутентификации/авторизации. Либо используйте Провайдер Профайла, как предложил Жаф - Бен Дугид, или реализуйте его самостоятельно.

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

Что-то вроде:

public UserDetails UserDetails
{
    get
    {
        UserDetails userDetails = Session["UserDetails"] as UserDetails;
        if (userDetails == null)
        {
            userDetails = GetUserDetailsFromDatabase(HttpContext.Current.User.Identity.Name);
            Session["UserDetails"] = userDetails;
        }
        return userDetails;
    }
}

Я знаю, что всегда могу обновить сеанс из БД, но я уже упоминал, что не хочу снова обращаться к БД, поскольку файл cookie аутентификации существует / действителен. Благодарю.
@zulq - «не желая снова попадать в БД, поскольку файл cookie аутентификации существует / действителен» - почему бы и нет? Если вы кешируете результат в сеансе, доступ будет редким. ИМХО сохранение аутентификации, авторизации и информации профиля независимо друг от друга уменьшает сцепление, что хорошо. Например, если вы переключитесь на аутентификацию Windows, ваша авторизация и функциональность профиля не будут нарушены, потому что больше нет куки-файла аутентификации.

Zhaph - Ben Duguid · Answer 2 · 2014-09-01T14-52-00.000Z

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

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

Если вы уверены, что не хотите использовать провайдера профиля (и есть причины не делать этого), тогда обязательно ознакомьтесь с ответом DanH на использование поля UserData AuthToken - но имейте в виду, что вам нужно будет генерировать (или воссоздавать) сам токен аутентификации - я не должен беспокоиться об этом, не говоря о Ролях, которые должны хорошо работать вместе с существующими методами.

Не уверен, что вы проверили первое сообщение по ссылке. Он на самом деле использует UserData в качестве ролей.
Не знаю , что ссылки вы имеете в виду, один на Danh в ответе явно говорит о сохранении имени в UserData поле?
Я имею в виду первую ссылку на пост. Я знаю, что ответ DanH использует UserData, но авторизация по первой ссылке использует UserData для ролей.
Я настоятельно рекомендую не хранить сведения о роли в поле UserData - это не то, что вы хотите отправить клиенту, где это может быть подделано (если я нарушу вашу процедуру шифрования и стану администратором, как вы узнаете? ). Храните данные о членстве в ролях на стороне сервера / базы данных, где вы можете ими управлять - если вы действительно хотите уменьшить количество поездок по базе данных, вы можете рассмотреть возможность добавления их в сеанс пользователей (так как в файле cookie присутствует только SessionId) ...