Подтвердить что ты не робот

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;
}
4b9b3361

Ответ 1

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

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

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

Ответ 2

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

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

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

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

Ответ 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'])."'";

Ответ 4

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

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

Ответ 5

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

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

Ответ 6

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

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

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

Воля

Ответ 7

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

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

Ответ 8

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

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

Ответ 9

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

Ответ 10

Я нашел сеансы очень полезными, но кое-что нужно отметить:

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

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

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

Ответ 11

Возможно, вам стоит подумать, как это REST-ful?

то есть. см. пункт "Сообщать без гражданства" в " Краткое введение в REST"...

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

(или любые другие ссылки на wikipedia для REST)

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

Ответ 12

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

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

Ответ 13

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

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

Ответ 14

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

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

Ответ 15

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