Сохранение данных вошедшего пользователя

Question

При создании веб-приложения, скажем, у вас есть объект User, обозначающий одного пользователя, как вы думаете, как лучше всего сохранить, что пользователь вошел в систему?

Я думал о двух способах:

• Сохранен идентификатор пользовательской базы данных в переменной сеанса.
• Сохранен весь объект пользователя в переменной сеанса.

Есть ли лучшие предложения, есть ли проблемы с использованием вышеуказанных способов?Возможно, проблемы с безопасностью или проблемы с памятью и т. д. и т. п.

Answer 1

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

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

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

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

Answer 2

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

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

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

Answer 3

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

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

Answer 4

В большинстве случаев лучше всего хранить идентификатор.Одной из важных причин этого является масштабируемость.Если вы сохраните объект пользователя (или любые объекты из базы данных, а не только их идентификаторы), вы столкнетесь с проблемами при увеличении количества серверов, обслуживающих ваш сайт.Для получения дополнительной информации в Google введите «архитектура без общего доступа».

Answer 5

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

Answer 6

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

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

Answer 7

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

Answer 8

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