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

Одна вещь, которую я начал делать чаще в последнее время, это получение некоторых данных в начале задачи и сохранение их в $_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;
}
Author: markus , 2008-09-17
Source

15 answers

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

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

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

 17
Author: HappySmileMan, 2016-01-28 13:40:06

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

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

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

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

 5
Author: dmitry, 2008-10-13 05:53:08

Я постоянно использую переменную сеанса для хранения информации для пользователей. Я не видел никаких проблем с производительностью. Данные сеанса извлекаются на основе файла 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'])."'";
 4
Author: Ryan Smith, 2016-01-19 09:27:31

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

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

 3
Author: pix0r, 2008-09-16 22:19:31

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

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

 3
Author: jfs, 2008-09-16 22:21:10

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

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

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

Будет

 2
Author: William Macdonald, 2008-09-16 22:47:31

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

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

 1
Author: nsayer, 2008-09-16 22:16:34

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

  • Кто-то может перехватить сеанс, поэтому, если вы собираетесь использовать его для отслеживания авторизации пользователей, будьте осторожны. Прочитайте это для получения дополнительной информации.
  • Это может быть очень ленивый способ хранения данных. Не просто бросайте все на сессии, чтобы что вам не придется запрашивать его позже.
  • Если вы собираетесь хранить объекты в сеансе, либо их файлы классов необходимо будет включить до запуска сеанса по следующему запросу, либо вам потребуется настроить автоматический загрузчик.
 1
Author: Lucas Oman, 2008-09-16 22:20:49

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

 1
Author: steve, 2008-09-16 22:25:58

Я обнаружил, что сеансы очень полезны, но следует отметить несколько вещей:

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

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

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

 1
Author: Mangor, 2008-09-17 00:03:11

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

Т.е. см. параграф "Общаться без состояния" в " Краткое введение в REST"...

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

.

(или любая другая ссылка в википедии для ОТДЫХ)

Итак, в вашем случае "wave_id" является разумным ресурсом для ПОЛУЧЕНИЯ, но вы действительно хотите сохранить его в СЕАНСЕ? Наверняка memcached - это ваше решение для кэширования ресурса объекта?

 1
Author: Matt, 2009-03-11 13:05:00

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

  1. $_SESSION срок действия данных истекает после сеанса.gc_maxlifetime секунд бездействия.
  2. Вам придется не забывать вызывать session_start() для каждого сценария, который будет использовать данные сеанса.
  3. Масштабирование веб-сайта путем балансировки нагрузки на нескольких серверах может быть проблемой, поскольку пользователя нужно будет каждый раз направлять на один и тот же сервер. Решите эту проблему с помощью "Липких сеансов".
 1
Author: Tom, 2009-04-20 11:20:38

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

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

 0
Author: Steve M, 2008-09-16 22:17:00

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

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

 0
Author: foxxtrot, 2008-09-16 22:23:04

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

 0
Author: Bryan Grezeszak, 2009-04-29 16:15:33