Хранение идентификатора пользователя в переменной сеанса

Question

Когда пользователь входит в систему (через open-id), мы создаем переменную сеанса с именем «UID» и сохраняем в ней уникальный идентификатор пользователя.Позже мы проверяем сессию, чтобы увидеть, вошел ли пользователь в систему. Я думаю, что это не правильный путь, но я не мог заставить команду изменить это, так как я не могу показать, как можно реализовать эту реализацию.Кто-нибудь может показать мне, почему (если да) эта реализация плоха?

Answer 1

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

Реализация кажется приемлемой, но, учитывая, что вы используете ASP.NET, вам следуетрассмотрите возможность использования IIdentity и этого провайдера ASP.NET OpenID:

http://code.google.com/p/dotnetopenid/

Он хорошо протестирован и имеет немало кода безопасности и встроенной поддержки API.

Answer 2

Мой первый вопрос: что заставляет вас думать, что это неправильный путь?

Хранение данных таким способом является очень распространенным, безопасным и локализованным специально для пользователя.Если вам не нравится использовать сеанс по другим причинам, таким как обработка сеансов на нескольких серверах или необходимость сериализации / десериализации сеанса в хранилище данных (при условии, что сеанс не связан с памятью), тогда это другой аргумент, но часть безопасности не должнаЭто не проблема.

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

РЕДАКТИРОВАТЬ на основе комментариев:

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

Answer 3

Как заявил Nissan Fan, я не вижу причин, по которым вы должны опасаться использования значения сеанса на стороне сервера.

Просто из любопытства, что вы думаете о том, что это неправильный путь?