Одна вещь, которую я начал делать чаще всего в последнее время, – это получение некоторых данных в начале задачи и сохранение ее в $ _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; } Ну переменные сеанса действительно являются одним из единственных способов (и, вероятно, наиболее эффективных) наличия этих переменных за все время пребывания посетителя на веб-сайте, нет реального способа для пользователя редактировать их (кроме эксплойта в вашем кода или интерпретатора PHP), поэтому они достаточно безопасны.
Это хороший способ сохранить настройки, которые могут быть изменены пользователем, так как вы можете прочитать настройки из базы данных один раз в начале сеанса, и он доступен для всего сеанса, вам нужно только делать дальнейшие вызовы базы данных, если настройки меняются и, конечно же, как вы показываете в своем коде, тривиально узнать, существуют ли уже существующие настройки или нужно ли их извлекать из базы данных.
Я не могу думать о каком-либо другом способе безопасного хранения временных переменных (поскольку файлы cookie могут быть легко изменены, и в большинстве случаев это будет нежелательно), поэтому $ _SESSION будет способом
Механизм $ _SESSION использует файлы cookie.
В случае Firefox (и, возможно, нового IE, я не проверял себя), это означает, что сеанс разделяется между открытыми вкладками . Это не то, что вы ожидаете по умолчанию. И это означает, что сеанс больше не «что-то конкретное для одного окна / пользователя».
Например, если вы открыли две вкладки для доступа к вашему сайту, чем зарегистрировались в качестве корня с использованием первой вкладки, вы получите привилегии root в другой.
Это действительно неудобно, особенно если вы кодируете почтовый клиент или что-то еще (например, интернет-магазин). В этом случае вам придется вручную управлять сеансами или вводить постоянно обновляемый ключ в URL-адрес или делать что-то еще.
Я использую переменную сеанса все время для хранения информации для пользователей. Я не видел никаких проблем с производительностью. Данные сеанса вытягиваются на основе файла 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'])."'";
Есть несколько факторов, которые вы захотите рассмотреть при выборе места хранения временных данных. Хранилище сеансов отлично подходит для данных, характерных для одного пользователя. Если вы обнаружите, что обработчик хранилища на основе файлов по умолчанию неэффективен, вы можете реализовать что-то еще, возможно, используя базу данных или тип memcache бэкэнд. Дополнительную информацию см. В разделе session_set_save_handler .
Я считаю, что плохая практика хранения общих данных в сеансе пользователя. Есть лучшие места для хранения данных, к которым часто обращаются несколько пользователей, и, сохраняя эти данные в сеансе, вы будете дублировать данные для каждого пользователя, которому нужны эти данные. В вашем примере вы можете настроить другой тип механизма хранения данных этой волны (на основе wave_id), который НЕ привязан специально к сеансу пользователя. Таким образом вы будете вытаскивать данные один раз, и они хранят его где-то, что несколько пользователей могут получить доступ к данным, не требуя другого притяжения.
Если вы работаете на своем собственном сервере или в среде, где никто не может отслеживать ваши файлы / память на сервере, данные сеанса являются безопасными. Они хранятся на сервере и только файл cookie, отправленный клиенту. Проблема в том, что другие люди могут вырвать куки и выдать себя за другого, конечно. Использование HTTPS и удостоверение того, что вы не помещаете идентификатор сеанса в URL-адреса, должны держать пользователей в безопасности от большинства этих проблем. (XSS все еще может быть использован для выхватывания файлов cookie, если вы не будете осторожны, см. Сообщение Jeef Atwoods об этом тоже.)
Что касается того, что хранить в переменной сеанса, поместите свои данные там, если вы хотите ссылаться на нее снова на другой странице, например, в корзине покупок, но не помещайте ее туда, если это временные данные, используемые для получения результата этого страницу, как список тегов для просматриваемого в данный момент сообщения. Сеансы предназначены для постоянных данных для каждого пользователя.
Еще один способ улучшить проверку ввода – это сбрасывать переменную _GET ['wave_id']:
$query_taskinfo = "SELECT participationcode, modulearray, wavenum FROM mng_wave WHERE wave_id=".(int)$_GET['wave_id']." LIMIT 1";
Я предполагаю, что wave_id является целым числом, и что есть только один ответ.
Будет
Элементы $ _SESSION хранятся в сеансе, который по умолчанию хранится на диске. Нет необходимости создавать свой собственный массив и записывать его в запись массива «dataentry», как вы это делали. Вы можете просто использовать $ _SESSION ['pcode'], $ _SESSION ['modules'] и так далее.
Как я уже сказал, сеанс хранится на диске, а указатель на сеанс хранится в файле cookie. Таким образом, пользователь не может легко получить данные сеанса.
ИМО, вполне приемлемо хранить вещи в сеансе. Это отличный способ сделать данные постоянными. Кроме того, это во многих случаях безопаснее, чем хранить все файлы cookie. Вот несколько проблем:
Zend Framework имеет полезную библиотеку для управления данными сеанса, которая помогает с истечением срока и безопасности (для таких вещей, как captchas). Они также имеют полезное объяснение сессий. См. http://framework.zend.com/manual/en/zend.session.html.
Я считаю, что сеансы очень полезны, но нужно отметить несколько вещей:
1) PHP может хранить ваши сеансы в папке tmp или другом каталоге, которые могут быть доступны другим пользователям на вашем сервере. Вы можете изменить каталог, поскольку сеансы хранятся, перейдя в файл php.ini.
2) Если вы настраиваете систему с высокими значениями, которая требует очень жесткой защиты, вы можете зашифровать данные перед отправкой на сеанс и расшифровать ее для ее использования. Примечание. Это может привести к слишком большим накладным расходам в зависимости от емкости вашего трафика / сервера.
3) Я обнаружил, что session_destroy (); не удаляет сеанс сразу, вам все равно придется ждать сборщика мусора PHP для очистки сеансов. Вы можете изменить частоту, с которой сборщик мусора запускается в файле php.ini. Но все еще не кажется очень надежным, больше информации http://www.captain.at/howto-php-sessions.php
Возможно, вам стоит подумать, как это REST-ful?
т.е. см. пункт «Сообщать без гражданства» в « Краткое введение в REST » …
«REST требует, чтобы состояние было либо преобразовано в состояние ресурса, либо сохранено на клиенте. Другими словами, серверу не нужно сохранять какое-либо состояние связи для любого из клиентов, с которыми он обменивается данными, выходящими за пределы одного запроса».
(или любые другие ссылки на wikipedia для REST )
Итак, в вашем случае «wave_id» – разумный ресурс для GET, но действительно ли вы хотите сохранить его на СЕССИИ? Конечно, memcached – это ваше решение для кэширования ресурса объекта?
Несколько других недостатков использования сеансов:
$_SESSION истекут после session.gc_maxlifetime секунд бездействия. session_start() для каждого скрипта, который будет использовать данные сеанса. Я использую этот подход справедливо, я не вижу никаких проблем с ним. В отличие от файлов cookie данные не хранятся на стороне клиента, что часто является большой ошибкой.
Как бы то ни было, просто будьте осторожны, что вы всегда дезинфицируете ввод пользователей, особенно если вы вводите пользовательский ввод в переменную $ _SESSION, а затем используете эту переменную в SQL-запросе.
Это довольно распространенная вещь, и сессия, как правило, будет быстрее, чем непрерывные обращения к базе данных. Они также достаточно безопасны, поскольку разработчики PHP много работали, чтобы предотвратить захват сеанса.
Единственная проблема заключается в том, что вам нужно помнить о том, чтобы перестроить запись сеанса, когда что-то изменится. И, если что-либо изменяется пользователем, отличным от того, кто владеет сеансом, что приведет к необходимости обновления этого ключа, нет простого способа уведомить систему об обновлении этого сеансового ключа. Возможно, это не большое дело, а то, о чем вы должны знать.
$ _SESSION очень полезна в безопасности, поскольку это серверный способ хранения информации, когда пользователь активно работает на ваших страницах, поэтому трудно взломать, если у вашего фактического файла или сервера php нет уязвимостей, которые используются. Одна очень хорошая реализация – это сохранение переменной, подтверждающей, что пользователь вошел в систему, и разрешает действие только в том случае, если они подтверждены во время входа в систему.