PHP - Какие данные мы должны включить в сеанс?

Question

Это вопрос для начинающих ...

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

Вообще говоря, какие данные имеют или не имеют своего места внутри таблицы сеанса?

Спасибо,

JDelage

Answer 1

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

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

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

Answer 2

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

Answer 3

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

Я предлагаю максимально свести к минимуму количество данных на вашем сеансе.

Answer 4

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

Answer 5

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

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

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

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

Одна из идей, с которой я недавно играл, заключается в хранении данных сеанса (ну, любых временных данных, где это нормально, чтобы потерять их в катастрофе) в базе данных NoSQL. CouchDB и MongoDB - мои текущие лучшие варианты для этого, но нет недостатка в других вариантах. CouchDB имеет отличное горизонтальное масштабирование, MongoDB смехотворно быстро работает при полной загрузке и т. Д.

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

Кроме того, экстернализация этих данных позволяет анализировать данные потенциально полезными способами. Запросите его, запустите метрики на нем, подключитесь к нему через другие веб-приложения или полностью автономные инструменты и т. Д. Это действительно открывает варианты по мере того, как проект растет сложнее.

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