PHP: $ _SESSION - каковы преимущества и недостатки хранения временно используемых данных в переменной $ _SESSION

Question

Одна вещь, которую я начал делать чаще всего в последнее время, это извлечение некоторых данных в начале задачи и сохранение их в $ _SESSION ['myDataForTheTask'] .

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

Например:

if (!isset($_SESSION['dataentry']))
{
    $query_taskinfo = "SELECT participationcode, modulearray, wavenum FROM mng_wave WHERE wave_id=" . mysql_real_escape_string($_GET['wave_id']);
    $result_taskinfo = $db->query($query_taskinfo);
    $row_taskinfo = $result_taskinfo->fetch_row();

        $dataentry = array("pcode" => $row_taskinfo[0], "modules" => $row_taskinfo[1], "data_id" => 0, "wavenum" => $row_taskinfo[2], "prequest" => FALSE, "highlight" => array());

        $_SESSION['dataentry'] = $dataentry;
}

Answer 1

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

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

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

Answer 2

$ _ Механизм SESSION использует куки.

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

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

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

Answer 3

Я постоянно использую переменную сеанса для хранения информации для пользователей. Я не видел никаких проблем с производительностью. Данные сеанса извлекаются на основе файла 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'])."'";

Answer 4

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

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

Answer 5

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

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

Answer 6

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

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

Answer 7

Еще один способ улучшить проверку ввода - привести переменную _GET ['wave_id']:

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

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

Будет

Answer 8

Возможно, вы захотите подумать, насколько это REST?

т.е. см. параграф «Общение без гражданства» в « Краткое введение в REST » ...

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

(или любые другие ссылки в википедии для REST )

Так что в вашем случае 'wave_id' является разумным ресурсом для GET, но вы действительно хотите сохранить его в СЕССИИ? Конечно, memcached - это ваше решение для кэширования объекта Resource?

Answer 9

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

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

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

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

Answer 10

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