Какие вещи должны быть сохранены в СЕССИИ, а какие не должны быть?

Question

Я приведу один пример, почему этот вопрос появляется в моей голове: допустим, я создаю класс 'PDOstart', который расширяет класс PDO.В классе 'PDOstart' все переменные, необходимые для PDO, определены в закрытом разделе (например, хост, пользователь, пароль и т. Д.).Поэтому очень просто использовать класс PDO, например:

$con = new PDOstart();
$con->query("SELECT ... ");

Поскольку на моей веб-странице я использую только одну БД, я начинаю думать, почему бы не добавить объект PDOstart в SESSION?как: $_SESSION['db'] = $con;?Так что мне не нужно на каждой странице делать "новый PODstart".Но я не уверен, что это будет хорошей идеей ...

Есть ли что-то, чего мне следует избегать, добавив к $ _SESSION (по соображениям безопасности или производительности)?

Answer 1

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

Как вы сказали $con позвольте мне кое-что объяснить.

В php есть несколько типов переменных, основными из которых являются:

• строка
• булево в
• целое число в
• объекты
• Массивы
• ресурсы

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

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

Основными объектами, которые вы должны хранить в сеансе, являются

• GUID : чтобы вы могли отслеживать, какой пользователь вошел в систему.
• Flash-данные : Таким образом, если вы делаете перенаправление, вы сможете отобразить сообщение об ошибке на другой странице.
• Данные браузера , так что вы можете сравнить, что браузер, который в данный момент просматривает, такой же, как и предыдущий, таким образом вы можете убить сеанс для безопасности.

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

Answer 2

Вы можете сохранить свой класс PDOstart в сеансе, если вы помните об этом:

• Когда вы делаете $ _SESSION ['key'] = $ objвы фактически сериализуете объект (предполагая, что обработчик сеанса php по умолчанию происходит, когда данные сбрасываются).
• Когда вы делаете это с «ресурсом», таким как соединение с базой данных, существует большая вероятность соединенияне будет сохраняться.
• Чтобы обойти такие случаи, php имеет магические методы __sleep и __wakeup

Я бы предположил, что ваш класс PDOstart обеспечит соединение с PDO как в __construct, так и в __wakeup, удвоивсложность.

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

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

Что касается безопасности, этот вид использования не должен иметь большого значения, если сеанс в целом безопасен.На самом деле это не так, но это совершенно другая тема.

Короткий ответ: хорошие вещи для хранения - идентификатор пользователя, плохие вещи для хранения - все остальное.

Answer 3

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

Затем, в зависимости от того, как хранится ваша сессия, вы должны быть осторожны с размером , который они принимают. скажем, вы храните его на очень быстром диске или в сервисе memcached, вам не нужно слишком беспокоиться о том, что этот файл будет читаться при каждом запросе вашего пользователя. Если у вас медленный ввод-вывод на вашем диске, будьте осторожны. Теперь, если вы сохраняете сеанс в базе данных, вы можете заботиться о ритме вставки / обновления / удаления в таблице сеансов, некоторые базы данных (например, MySQL) не очень хороши в обработке высокой нагрузки записи для одной таблицы.

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