PyroCMS/Codeigniter: слишком много записей сеанса в БД

Я использую для небольшого веб-сайта комбинацию pyrocms / codeigniter. после добавления некоторого контента я проверил БД и увидел, что: множественный идентификатор сеанса

это нормальное поведение? несколько session_ids для одного пользователя с одним и тем же ip? я не могу представить, что это правильно.

моя конфигурация сеанса выглядит так:

$config['sess_cookie_name']     = 'pyrocms' . (ENVIRONMENT !== 'production' ? '_' . 

ENVIRONMENT : '');
$config['sess_expiration']      = 14400;
$config['sess_expire_on_close'] = true;
$config['sess_encrypt_cookie']  = true;
$config['sess_use_database']    = true;
// don't change anything but the 'ci_sessions' part of this. The MSM depends on the 'default_' prefix
$config['sess_table_name']      = 'default_ci_sessions';
$config['sess_match_ip']        = true;
$config['sess_match_useragent'] = true;
$config['sess_time_to_update']  = 300;

я не изменил строку кода, влияющую на класс сеанса или что-то в этом роде.

строки красной шляпы относятся к 15-минутной работе cron. это нормально я думаю.

каждый раз, когда обновляется страница, добавляются две или три новых записи session_entries...


database session codeigniter pyrocms
person Jens    schedule 16.05.2013    source источник
comment
stackoverflow.com/q/2438835/183254 что-нибудь там поможет?   -  person stormdrain    schedule 27.05.2013
comment
Спасибо за помощь, но боюсь, что нет ;(   -  person Jens    schedule 28.05.2013

Ответы (1)


arrow_upward
4
arrow_downward

Да, это нормально. Класс сеанса CI периодически автоматически генерирует новый идентификатор. (По умолчанию каждые 5 минут.) Это часть безопасности, присущая использованию сеансов CI вместо собственных сеансов PHP. Сборка мусора позаботится об этом, вам не нужно ничего делать.

Подробнее о поведении идентификатора сеанса можно прочитать в руководстве по CI. Это отрывок, скопированный с этой страницы.

Уникальный идентификатор сеанса пользователя (это статистически случайная строка с очень сильной энтропией, хешированная с помощью MD5 для переносимости и регенерируемая (по умолчанию) каждые пять минут)

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

Если вас это действительно беспокоит, вы можете изменить время ожидания в основном файле конфигурации CI. Изменить строку

$config['sess_time_to_update'] = 300 (5-минутный период обновления)

до числа большего, чем

$config['sess_expiration'] (по умолчанию 7200)

Это приведет к тайм-ауту сеанса, прежде чем он будет восстановлен. Теоретически это по своей сути менее безопасно, но, если вы не передаете конфиденциальные данные, на практике это, вероятно, не имеет значения.

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

person colonelclick    schedule 28.05.2013
comment
В руководстве ничего не упоминается ни о 5-минутном обновлении, ни о поведении id. Но, глядя на источник похоже, что он обновляется каждые 5 минут, но также похоже, что он пытается обновить существующий сеанс, если установлен соответствующий ip и/или соответствующий пользовательский агент. Думаете, это исправит дублированные записи? - person stormdrain; 29.05.2013
comment
удлинил мой ответ, чтобы учесть ваши комментарии - person colonelclick; 29.05.2013
comment
У меня есть одно небольшое слепое пятно в левом глазу ... должно быть, оно было там, где была эта линия;) Спасибо за расширение вашего ответа. - person stormdrain; 29.05.2013
comment
Ю.В. Я надеюсь, что это отвечает на все вопросы. - person colonelclick; 29.05.2013
comment
Но Session IDS будет создаваться при каждом обновлении страницы. Как бы вы это объяснили? - person Jens; 30.05.2013
comment
В этом я не уверен, я не видел такого поведения в своей работе. Возможно, у вас устаревшие или измененные системные файлы? Было бы легко удалить системную папку и установить текущую версию для проверки. Сначала сделайте резервную копию, естественно. - person colonelclick; 02.06.2013