Хранение сведений о пользователе, вошедшем в систему

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

1. Если информация пользователя каким-то образом изменится, то вы не будете хранить информацию out-of-date в своем сеансе. Например, если пользователь получает дополнительные привилегии от администратора, то они будут немедленно доступны без необходимости выхода из системы и последующего входа в систему.

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

В большинстве случаев эти проблемы не будут проблемой, и любой подход будет прекрасным.

В целях безопасности я бы сгенерировал (либо GUID, либо криптографически безопасный RNG) сеанс ID и имел таблицу, которая просто сопоставляет сеанс IDs пользователю IDs. Затем вы просто сохраняете сеанс ID в своих файлах cookie и заставляете его действовать как прокси для идентификатора пользователя.

|Session |UserID |
|--------+-------|
|a1d4e...+ 12345 |
|--------+-------|
|c64b2...+ 23456 |
|--------+-------|

При этом никто не может выдать себя за другого пользователя, угадав его ID. Он также позволяет ограничить сеансы пользователей, так что они должны входить в систему очень часто (обычно две недели). И если вы хотите сохранить другие данные об их сеансе, вы можете просто добавить их в эту таблицу.

Просто помните,что если вы сохраняете все атрибуты пользователя (это распространяется на разрешения) в сеансе, то любые изменения для пользователя не вступят в силу, пока он не войдет снова.

Лично я храню имя и идентификатор для быстрого ознакомления и извлекаю rest, когда мне это нужно.

Хранение ID-это лучшая практика в большинстве случаев. Одной из важных причин этого является масштабируемость. Если вы храните объект пользователя (или любые объекты из базы данных, а не только их IDs), вы столкнетесь с проблемами расширения числа серверов, обслуживающих ваш сайт. Для получения дополнительной информации, google for "shared nothing architecture".

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

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

Я думаю, что это зависит от того, какую платформу вы используете. Если вы используете ASP.net, то я бы определенно взглянул на класс FormsAuthentication и все встроенные (и расширяемые) функциональные возможности, которые вы можете использовать для хранения ваших учетных пользовательских настроек.

Обычно я сохраняю пользователя в сеансе. Проблему входа в систему can ' t-change-until можно решить, заменив объект в сеансе новой копией после внесения изменений.

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