Я никогда не думал делать это раньше, и я не уверен в рисках. Это одноразовый сеанс для каждой страницы, который заменяется следующей посещенной страницей.
Какой риск безопасности сделать что-то вроде следующего? Если есть?
$_SESSION['somename'] = "SELECT `something` FROM `table` WHERE `something`='blah'";
Является ли этот метод безопасным, если нет, то какой безопасный способ хранить одноразовый запрос, который будет заменен?
Вероятно, безопаснее хранить запросы в таблице временных mysql. Но я хочу избежать дополнительных вызовов MySQL.
Это небезопасный способ установить переменную с помощью PHP из-за возможности раскрытия имен таблиц, которые потенциально могут быть УДАЛЕНЫ с помощью SQL-инъекции. Теперь переменные сеанса хранятся на сервере и недоступны для браузера. Однако зачем вводить дурную привычку, которая может заставить кого-то менее опытного в вашей команде разработчиков использовать это для установки cookie? Тогда у вас есть большая проблема, которая стала доброкачественной. Лучше просто поместить данные в переменные сеанса PHP, которые действуют как идентификатор пользователя.
Это не должно быть слишком вредно (см. Ниже), но это плохая практика.
Запросы к БД — это уровень данных / модели, а управление сессиями — совершенно другая тема. Вы бы сделали себе огромную услугу в держать эти отдельно.
Кроме того, если вам нужно что-то кэшировать, вы должны кэшировать Результаты, не запросы. Однако вы можете убедиться, что результат привязан к пользователю, добавив идентификатор к результату.
Например, вы можете сохранить результат запроса БД в массиве в Memcached, где ключ массива будет идентификатором пользователя.
Если вы беспокоитесь о производительности вызовов MySQL, вам следует обратить внимание на нормализацию и правильную индексацию.
Одно замечание о потенциальном вреде: данные сеанса хранятся в файловой системе или (редко) в памяти. В системах с общим хостингом могут быть реализованы или не реализованы меры, препятствующие прочтению данных вашего сеанса другими пользователями. С другой стороны, ваш исходный код PHP также доступен для чтения в виде открытого текста и, как правило, имеет те же разрешения, поэтому дополнительного вектора атаки нет. Реальная угроза безопасности была бы введена, если бы другие могли записывать к вашим данным сеанса. Но я надеюсь, что на машинах серьезных хостинговых компаний нет таких настроек.