Управление сессиями | Руководство по PHP

Вернуться к: Расширения для работы с сессиями

  • Введение
  • Установка и настройка
    • Требования
    • Установка
    • Настройка во время выполнения
    • Типы ресурсов
  • Предопределенные константы
  • Примеры
    • Основы использования
    • Передача идентификатора сессии
    • Пользовательские обработчики сессии
  • Отслеживание прогресса загрузки файлов с помощью сессий
  • Безопасность сессий
  • Функции для работы с сессиями
    • session_abort — Discard session array changes and finish session
    • session_cache_expire — Return current cache expire
    • session_cache_limiter — Get and/or set the current cache limiter
    • session_commit — Псевдоним session_write_close
    • session_decode — Decodes session data from a session encoded string
    • session_destroy — Destroys all data registered to a session
    • session_encode — Encodes the current session data as a session encoded string
    • session_get_cookie_params — Возвращает параметры cookie сессии
    • session_id — Get and/or set the current session id
    • session_is_registered — Определяет, зарегистрирована ли глобальная переменная в сессии
    • session_module_name — Возвращает и/или устанавливает модуль текущей сессии
    • session_name — Get and/or set the current session name
    • session_regenerate_id — Update the current session id with a newly generated one
    • session_register_shutdown — Функция завершения сессии
    • session_register — Register one or more global variables with the current session
    • session_reset — Re-initialize session array with original values
    • session_save_path — Get and/or set the current session save path
    • session_set_cookie_params — Set the session cookie parameters
    • session_set_save_handler — Sets user-level session storage functions
    • session_start — Start new or resume existing session
    • session_status — Возвращает состояние текущей сессии
    • session_unregister — Unregister a global variable from the current session
    • session_unset — Free all session variables
    • session_write_close — Write session data and end session
  • SessionHandler — The SessionHandler class
    • SessionHandler::close — Close the session
    • SessionHandler::create_sid — Return a new session ID
    • SessionHandler::destroy — Destroy a session
    • SessionHandler::gc — Cleanup old sessions
    • SessionHandler::open — Initialize session
    • SessionHandler::read — Read session data
    • SessionHandler::write — Write session data
  • SessionHandlerInterface — The SessionHandlerInterface class
    • SessionHandlerInterface::close — Закрывает сессию
    • SessionHandlerInterface::destroy — Уничтожает сессию
    • SessionHandlerInterface::gc — Очищает старые сессии
    • SessionHandlerInterface::open — Initialize session
    • SessionHandlerInterface::read — Читает данные сессии
    • SessionHandlerInterface::write — Записать данные сессии

Вернуться к: Расширения для работы с сессиями

MODX, PHP и сборка мусора в сессиях / Русскоязычное сообщество MODX

Вольный перевод свежей статьи от Марка Хамстры.

Когда вы в последний раз проверяли размер таблицы modx_session? Не измерялся ли он в гигабайтах? Если это так, вы не одиноки.

Чтобы понять проблему нужно немного предыстории.

Как работают сессии в PHP?

Обычно стандартный PHP обработчик создает сессию по запросу и сохраняет ее в виде простого файла где-то в системе. Путь, где сохраняется сессия, настраивается с помощью параметра session.save_path в php.ini и может указывать куда угодно. Когда эта опция пуста, сессия записывается во временный каталог на сервере.

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

Сборка мусора не должна выполняться при каждом запросе. Если время жизни вашей сессии/куки-файла задано равным неделе, и вы не слишком требовательны к точному времени, когда они удаляются, тогда сессии нужно проверять только один раз в день. Очистка сессий может потребовать некоторого времени и ресурсов, поэтому PHP по умолчанию настроен на выполнение этого только один раз каждые 100 запросов.

Как работают сессии в MODX?

MODX создает обработчик, который следит за сохранением, получением и очисткой сессий. Он записывает их в одну из своих собственных таблиц базы данных (

modx_session), а не в файлы. Это дает MODX немного больше контроля над потоком сессий.

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

Итак, почему MODX не очищает свою таблицу сессий?

MODX ожидает сигнала от PHP, что пришло время очистить сессии. За это отвечают два следующие параметра конфигурации в PHP:

session.gc_probability
session.gc_divisor

Вы можете найти официальную документацию для этих параметров здесь.

Обычно в session.gc_probability устанавливается значение равным 1, а в session.gc_divisor — значение, подобное 100 или 1000. Это означает, что примерно в 1/100 запросов будет выполняться сборка мусора.

Когда кажется, что MODX не очищает свою таблицу, это обычно происходит из-за попытки улучшить качество сборки мусора, обходя PHP и выгружая ее в задание по cron’у, которое выполняется вне цикла «запрос-ответ».

Предполагается, что PHP записывает свои сессии в стандартное местоположение файловой системы и очищает этот каталог на основе метки времени в файле. Параметр session.gc_probability

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

Это работает прекрасно — в случае, если ваши сессии хранятся обычным образом. Однако, у MODX это не так.

Как часто это происходит?

Основываясь на данных из SiteDash, который автоматически проверяет размер и состояние вашей таблицы сессии, это случается довольно часто. Из выбранных 1727 сайтов 27% похоже сталкиваются с этим.

Как я могу это исправить?

Добавьте параметр session.gc_probability. Установите его значение в 1 и убедитесь, что session.gc_divisor также настроен правильно для вашего трафика.

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

сессий WordPress и PHP | PHP на Pantheon

Узнайте больше о поведении сеансов WordPress и PHP.

Обсудить на нашем форуме Обсудить в Slack

Редактировать эту страницу на GitHub  | Сообщить о проблеме с этим документом

В этом разделе содержится информация о сеансах WordPress и PHP.

WordPress Core не использует сеансы. Все «состояние пользователя» управляется с помощью файлов cookie. Это ключевое дизайнерское решение.

Однако некоторые плагины или темы будут использовать session_start() или PHP $_SESSION superglobal. Вы должны использовать поддерживаемый Pantheon плагин WordPress Native PHP Sessions, чтобы использовать PHP Sessions в Pantheon.

 Предупреждение

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

Устранение ошибок сеанса

Перед установкой WordPress Native PHP Sessions вы можете увидеть следующую ошибку:

 Предупреждение: session_start(): функции пользовательского сеанса не определены

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

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

$_SESSIONS Включено

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

Лучше всего использовать решение на основе файлов cookie, чтобы избежать падения производительности из-за некэшированных страниц сеанса.

Признаки этой проблемы можно обнаружить, проверив заголовок. Файл cookie сеанса всегда устанавливается при каждой загрузке страницы:

 Set-Cookie: SESS1234XXXXXXXXXXXXXX path=/; домен=.example.pantheonsite.io; HttpOnly

Лучший способ определить, какой плагин или тема препятствует кэшированию, — это найти в коде плагина и темы вашего сайта функцию session_start() PHP:

 cd wp-content
grep -rnw . -e 'session_start'

Кроме того, вы можете проверить заголовки, используя curl -sI example.com после каждого из следующих шагов, пока не определите, какой компонент нарушает кэш:

  1. Используйте тему по умолчанию например) и проверьте файл cookie.

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

    Примечание. Если у вас есть локальная копия вашего сайта, вы можете найти в ней плагины, использующие session_start() или $_SESSIONS , и сначала начать отключать их.

  3. Удалите (временно) сторонние обязательные плагины и оставьте только Pantheon и WP Native PHP Sessions , чтобы проверить, не нарушает ли кеш сторонний обязательный плагин или вставной плагин. На месте не должно быть вставок.

Установите плагин WordPress Native PHP Sessions

Установите плагин WordPress Native PHP Sessions, если $_SESSIONs необходимы для вашего приложения:

  1. Установите режим подключения SFTP для среды Dev или Multidev через панель управления Pantheon или с конечной:

     терминальное соединение: установить . sftp

  2. Установить и активировать собственные PHP-сессии WordPress из панели инструментов WordPress среды Dev или Multidev ( /wp-admin/plugin-install. php?tab=search&s =wp+native-php-sessions ) или с помощью Terminus:

     terminus wp . -- установка плагина wp-native-php-sessions --activate

  3. Зафиксируйте свои изменения через панель управления сайтом или с конечной:

     terminus env:commit --message «Добавление плагина собственных сеансов php» -- .

    (дополнительные параметры для этой команды)

  4. Объедините свои изменения в Dev, если вы работаете над Multidev :

     terminus multidev:merge-to-dev -- .

    (дополнительные параметры для этой команды)

  5. Разверните подключаемый модуль в тестовой среде на панели управления сайтом или с помощью Terminus:

     termus env:deploy <сайт>.test --sync-content --updatedb --note="Установить плагин WordPress Native PHP Sessions"

    (дополнительные параметры для этой команды)

  6. Активируйте плагин в панели инструментов WordPress в тестовой среде ( /wp-admin/plugins. php ) или с помощью Terminus:

     terminus wp .test - - plugin активировать wp-native-php-sessions

  7. Разверните плагин в среде Live на панели управления сайтом или с помощью Terminus:

     terminus env:deploy .live --note="Install WordPress Native PHP Sessions плагин"

    (дополнительные параметры для этой команды)

  8. Активируйте плагин в панели управления WordPress в среде Live ( /wp-admin/plugins.php ) или с помощью Terminus:

     terminus wp .live - - активация плагина wp-native-php-sessions

Для получения дополнительной информации см. Устранение проблем PHP-сессии WordPress в Pantheon с помощью скрипта.

Сеансы и масштабируемость

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

Наш плагин предоставляет экран администратора, чтобы увидеть, сколько сеансов было запущено. Вы также можете проверить заголовки, отправляемые вашим сайтом. Если вы открываете новое окно в режиме инкогнито и видите, что в ответ на запрос вашего сайта отправляется файл cookie PHPSESS , значит, у вас слишком интенсивный код сеанса.

Пользователи командной строки могут использовать этот быстрый фрагмент для тестирования:

 curl -Is https://www.getpantheon.com | grep PHPSESS|wc -l

Вы должны заменить URL своего сайта в примере, и желаемый результат будет «0» (ноль).

Если ваш сайт слишком агрессивно запускает сеансы, вам следует поискать в кодовой базе ссылки на session_start() или $_SESSION , чтобы увидеть, где это происходит, и разработать обходной путь. Если код находится в плагине сообщества, откройте задачу на WordPress.org, чтобы предупредить автора о проблеме и поделиться своим решением.

Дополнительные ресурсы

  • Требования WordPress PHP

  • Настройте файл wp-config. php

Файлы cookie и сеансы PHP — Центр поддержки

Центр поддержки

Последнее обновление: 20 января 2023 г.

Cachecookiesdevelopmentphp

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

Печенье

Термин «куки» относится к контекстуальным битам данных, которые хранит ваш веб-браузер. Файл cookie может использоваться для отображения различной информации на веб-сайте для разных пользователей или для сбора данных об активности пользователя в Интернете.

Файлы cookie назначаются отдельным пользователям, что означает, что они не предназначены для нескольких пользовательских сеансов. Сохраняемые данные должны иметь возможность возвращать уникальное значение и применять уникальный набор правил. ПРИМЕР: Если вы хотите, чтобы на вашем сайте отображалось всплывающее окно для пользователей, которым 9 лет,0200 уже подписчик, по сравнению с пользователями, у которых , а не подписчик, может помочь файл cookie.

Проблемы с файлами cookie

При наличии файлы cookie работают с PHP при загрузке страницы для выполнения уникального действия. Когда страница обслуживается из кеша, она уже была сгенерирована ранее сервером. Если страница кэшируется, файл cookie не может быть сгенерирован и выполняет свое действие при загрузке страницы, как ожидалось.

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

Мы рекомендуем заполнить все доступные параметры для действия, которое вы хотите выполнить с помощью HTML или PHP. Затем вы можете использовать JavaScript, чтобы выбрать вариант загрузки (в зависимости от наличия файла cookie). Таким образом, полностью сформированная страница, обслуживаемая кешем, по-прежнему будет соответствовать всем сценариям, поскольку JavaScript на стороне браузера будет определять, какие из доступных параметров будут отображаться.

В примере, использующем очень простой условный HTML, код говорит показывать одно изображение боковой панели при посещении предпочтительным пользователем и другое изображение для тех, кому необходимо зарегистрироваться. Затем JavaScript будет читать заголовок $_COOKIE, чтобы определить, какое изображение боковой панели показывать.

Альтернативы файлам cookie

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

Использовать вызовы Admin-ajax

  • JavaScript запускает запрос POST к admin-ajax. php. Затем PHP может получать и, при необходимости, выполнять различные действия.
  • Этот сценарий следует использовать только в том случае, если ваша страница не отправляет никаких других запросов admin-ajax. Отправка нескольких запросов к admin-ajax.php не идеальна и напрямую сводит на нет преимущества этого метода.
  • Пример можно найти здесь

Исключить страницы из кэша при наличии файлов cookie

  • Страница обновляется на PHP для ваших пользователей только при наличии файла cookie.
  • Примечание. Раскэширование страниц плохо масштабируется при увеличении трафика.
  • Обратитесь за помощью в службу поддержки на своем пользовательском портале.

Сеансы PHP

Сеансы PHP — это биты данных о пользователе, предназначенные для хранения пользователями во время навигации по вашему сайту. Сессия PHP включает установку файла cookie с именем PHPSESSID с уникальной идентификационной строкой в ​​качестве значения.

EX: Хранение данных корзины покупок, недавно просмотренных товаров или состояния входа в систему на нескольких страницах.

Проблемы с сессиями

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

Сессии PHP также сохраняют данные в файловой системе как собственный уникальный файл. Запись данных в файл — это процесс ввода-вывода, который, как известно, создает резервную копию и вызывает высокую нагрузку на сервер. Этот тип хранилища сеансов также просто не работает, если ваш сайт находится в кластерном решении AWS, охватывающем несколько веб-серверов.

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

No related posts.