Когда вы создаете веб-приложение и допустим, что у вас есть объект User, обозначающий одного пользователя, что, по вашему мнению, является лучшим способом хранения того, что пользователь вошел в систему?
Два способа, о которых я думал, были:
- Хранит идентификатор базы данных пользователя в переменной сеанса
- Хранит весь пользовательский объект в переменной сеанса
Любые лучшие предложения, какие-либо проблемы с использованием вышеуказанных способов? Возможно, проблемы безопасности или памяти и т. Д. И т. Д.
Я рекомендую хранить идентификатор, а не объект. Недостатком является то, что вам нужно обращаться к базе данных каждый раз, когда вы хотите получить информацию об этом пользователе. Однако, если на вашей странице не учитывается каждая миллисекунда, производительность не должна быть проблемой. Вот два преимущества:
Если информация пользователя каким-либо образом изменится, вы не будете хранить устаревшую информацию в своем сеансе. Например, если пользователю предоставлены дополнительные привилегии администратором, то они будут немедленно доступны без необходимости выхода пользователя из системы и повторного входа в систему.
Если информация о вашем сеансе хранится на жестком диске, вы можете хранить только сериализуемые данные. Таким образом, если ваш объект User когда-либо содержит что-либо, например, соединение с базой данных, открытый сокет, дескриптор файла и т. Д., То это не будет храниться должным образом и не может быть очищено должным образом.
В большинстве случаев эти проблемы не будут проблемой, и любой подход будет в порядке.
Просто помните, что если вы сохраняете все атрибуты пользователя (это распространяется на разрешения) в сеансе, то любые изменения для пользователя не вступят в силу, пока они не войдут снова.
Лично я храню имя и идентификатор для быстрого ознакомления, а остальное извлекаю, когда мне это нужно.
Я думаю, что это зависит от того, какую платформу вы используете. Если вы используете ASP.net, то я бы определенно взглянул на класс FormsAuthentication и все встроенные (и расширяемые) функциональные возможности, которые вы можете использовать для хранения настроек пользователя, вошедшего в систему.
Хранение идентификатора является лучшей практикой в большинстве случаев. Одной из важных причин этого является масштабируемость. Если вы храните пользовательский объект (или какие-либо объекты из базы данных, а не только их идентификаторы), вы столкнетесь с проблемами, связанными с увеличением количества серверов, обслуживающих ваш сайт. Для получения дополнительной информации, Google для "архитектуры ничего не поделился".
Я обычно храню пользователя в сеансе. Проблема не может быть изменена до входа в систему может быть решена путем замены объекта в сеансе новой копией после внесения изменений.
Наш пользовательский объект довольно легкий, поэтому мы решили сохранить его в переменной сеанса. Не уверен, что это наиболее эффективно, но пока все работает очень хорошо.
В целях безопасности я бы сгенерировал (или GUID, или криптографически безопасный RNG) идентификатор сеанса и имел бы таблицу, которая просто отображает идентификаторы сеансов в идентификаторы пользователей. Затем вы просто сохраняете идентификатор сеанса в их файлах cookie, и он действует как прокси для идентификатора пользователя.
|Session |UserID |
|--------+-------|
|a1d4e...+ 12345 |
|--------+-------|
|c64b2...+ 23456 |
|--------+-------|
При этом никто не может выдать себя за другого пользователя, угадав его идентификатор. Это также позволяет ограничивать сеансы пользователей, поэтому им приходится заходить в систему очень часто (обычно две недели). И если вы хотите хранить другие данные об их сеансе, вы можете просто добавить их в эту таблицу.
Я хотел бы сохранить хешированное значение идентификатора пользователя и идентификатора сеанса, а затем сопоставить его в таблице сеансов в базе данных. Таким образом, будет сложнее подделать данные сеанса. Могу ли я проверить на IP тоже в качестве дополнительной проверки.
Не уверен, что я хотел бы полагаться на идентификатор пользователя, хранящийся в переменной сеанса, и полагать, что это был тот пользователь, поскольку его можно было довольно легко изменить и получить доступ в качестве другого члена