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

Это - довольно общая вещь сделать, и сессия обычно будет быстрее, чем непрерывные хиты базы данных. Они также довольно безопасны, поскольку PHP devs упорно работали для предотвращения Перехвата сеанса.

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

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

Как что-либо, хотя, просто быть осторожным, что Вы всегда санируете ввод данных пользователем, особенно при помещении ввода данных пользователем в $ _SESSION переменная, тогда более позднее использование что переменная в SQL-запросе.

Вы могли бы хотеть рассмотреть, насколько УСПОКОИТЕЛЬНЫЙ это?

т.е. видят, "Передают statelessly" абзац в" Введение Резюме А в REST"...

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

(или какая-либо из других ссылок на Википедию для REST)

Так в Вашем случае, 'wave_id' является разумный Ресурс для ПОЛУЧЕНИЯ, но сделать Вас действительно хотят сохранить его на СЕССИИ? Конечно memcached является Вашим решением cacheing объектный Ресурс?

Я нашел, что сессии очень полезны, но несколько вещей отметить:

1), Что PHP может сохранить Ваши сессии в tmp папке или другом каталоге, который может быть доступен для других пользователей на Вашем сервере. Можно измениться, каталог были сессии, хранятся путем движения в файл php.ini.

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

3) я нашел это session_destroy (); doesn’t удаляют сессию сразу же, все еще необходимо ожидать сборщика "мусора" PHP для чистки сессий. Можно изменить частоту, что сборщик "мусора" запущен в файле php.ini. Но все еще doesn’t, кажутся очень надежными, больше информации http://www.captain.at/howto-php-sessions.php

IMO, совершенно приемлемо сохранить вещи на сессии. Это - отличный способ сделать данные персистентными. Это также, во многих случаях, более безопасно, чем хранение всего в cookie. Вот несколько проблем:

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

Платформа зенда имеет полезную библиотеку для управления данными сессии, которое помогает с истечением и безопасностью (для материала как капчи). У них также есть полезное объяснение сессий. См. http://framework.zend.com/manual/en/zend.session.html

Если Вы работаете на своем собственном сервере, или в среде, где никто не может шпионить на Ваших файлах/памяти на сервере, данные сессии безопасны. Они хранятся на сервере и просто идентификационном cookie, отправленном клиенту. Проблема состоит в том, если другие люди могут схватить cookie и исполнить роль кого-то еще, конечно. Используя HTTPS и удостоверяющийся не помещать идентификатор сессии в URL должен охранять Ваших пользователей от большинства тех проблем. (XSS мог бы все еще использоваться для хватания cookie, если Вы не осторожны, см. сообщение Jeef Atwoods на этом также.)

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

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

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

$ _SESSION механизм использует cookie.

В случае Firefox (и возможно новый IE, я не проверялся), который означает, что сессия совместно используется открытыми вкладками . Это не что-то, что Вы ожидаете по умолчанию. И это означает, что сессия больше не является "чем-то характерным для единственного окна/пользователя".

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

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

$ _SESSION объекты хранятся на сессии, которая, по умолчанию, сохранена диск. Нет никакой потребности сделать Ваш собственный массив, и наполнить его в 'dataentry' записи массива как Вы сделало. Можно просто использовать $ _SESSION ['псевдокод'], $ _SESSION ['модули'] и так далее.

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

Другой способ улучшить контроль ввода состоит в том, чтобы бросить _GET ['wave_id'] переменная:

$query_taskinfo = "SELECT participationcode, modulearray, wavenum FROM mng_wave WHERE wave_id=".(int)$_GET['wave_id']." LIMIT 1";

Я предполагаю, что wave_id является целым числом, и что существует только один ответ.

Будет

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

Только для сообщения, хотя, у Вас действительно есть проблема безопасности с Вашим SQL-оператором:

SELECT participationcode, modulearray, wavenum FROM mng_wave WHERE wave_id=".$_GET['wave_id'];

Вы никогда не должны, я никогда ПОВТОРЯЮСЬ, беру обеспеченные данные пользователя и используй их для выполнения SQL-оператора без первой очистки их. Я перенес бы его в кавычки и добавил бы функцию mysql_real_escape_string(). Это защитит Вас от большинства нападений. Таким образом, Ваша строка была бы похожа:

$query_taskinfo = "SELECT participationcode, modulearray, wavenum FROM mng_wave WHERE wave_id='".mysql_real_escape_string($_GET['wave_id'])."'";

Несколько других недостатков использования сеансов: истечение срока действия данных

1. $ _ SESSION после сеанса .gc_maxlifetime секунд бездействия.
2. Вы должны будете не забывать вызывать session_start () для каждого скрипта, который будет использовать данные сеанса.
3. Масштабирование сайта путем балансировки нагрузки по нескольким Серверы могут быть проблемой, потому что пользователь должен быть направлен на один и тот же сервер каждый раз. Решите это с помощью «Sticky Sessions».

$ _ SESSION очень полезен в плане безопасности, поскольку это серверный способ хранения информации, пока пользователь активно находится на ваших страницах, поэтому его трудно взломать, если у вашего фактического php-файла или сервера нет слабых мест которые эксплуатируются. Одна очень хорошая реализация хранит переменную, чтобы подтвердить, что пользователь вошел в систему, и позволяет выполнять действия, только если они подтверждены, что они вошли в систему.