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

Question

У меня есть приложение php, и я сохраняю переменные сеанса для пользователя, используя сам $ _SESSION. Есть ли какое-то конкретное преимущество его хранения в базе данных?

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

Answer 1

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

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

Любые данные, которые необходимо хранить в течение длительного времени, такие как данные пользователя и действия, которые я храню в базе данных. Любые данные, которые имеют отношение только к текущему рабочему пространству, такие как вход на сайт, размещение нескольких комментариев и т. Д., Могут быть сохранены в сеансе. Например, я храню данные аутентификации пользователя в сеансе, чтобы постоянно проверять, вошел ли пользователь в систему или нет, и перенаправлять ли его / ее на правильную страницу.

Это чудесно работает при проверке прав доступа по всему вашему приложению.

Для меня гораздо безопаснее хранить пользовательские данные в базе данных, потому что они не могут быть доступны публично, как $ _SESSION.

Пожалуйста, не соглашайтесь со мной, если хотите.

Answer 2

Я бы сказал, лучше хранить в базе данных. Потому что

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

2. Вы можете легко отслеживать пользователей и их статус.

3. Для приложений, работающих на нескольких серверах, вы можете сохранить все данные сеанса в одной базе данных.

Эта статья может помочь.

Answer 3

Ну, это вопрос на века. Лично из того, что я узнал в свое время. Если ваш сайт не начинает массово развиваться, когда вам нужно начать использовать несколько серверов для различных аспектов системы, таких как балансировка нагрузки, когда у вас работает много зеркальных систем. Или нужно немного повысить производительность для перенаселенной системы, преимущества использования сессий, связанных с БД, или файловых сессий на самом деле ничем не отличаются. Да, я могу ошибаться, это просто мое личное восприятие на основе моего собственного опыта. Так же, как и вы, я никогда не находил никаких статей, постов, других, которые действительно ставили бы один на один бок с чертом, я даже не думаю, что нашел что-то, что действительно ставит один на один в этом отношении. Лично я просто следую тому, что когда-либо необходимо (или желанию моего клиента), обычно я просто придерживаюсь родных сессий на основе файлов.

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

Answer 4

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

Учтите это:

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

Session + DB Option. Это просто хранит идентификатор сеанса, который ссылается на строку в базе данных. Все, что мне нужно сделать, чтобы изменить сеанс, который я хочу, это сломать шифрование сеанса и сказать добавить один к идентификатору сеанса. Тогда я буду аутентифицирован как пользователь, который вошел после меня.

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

Answer 5

Из моего короткого опыта вы должны хранить в $_SESSION только те данные, которые НЕ нужно обновлять во всех сеансах, открытых уникальным пользователем на разных устройствах . (Мобильный / настольный / др.)

Другими словами, данные, которые, как вы уверены, никогда не изменятся, как идентификатор пользователя .

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

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

Очень временные данные также могут храниться в $_SESSION, я думаю.

Примечание: из этих аргументов основная потребность в глобальном сеансе заключается в , чтобы переменные были доступны глобально