Вообще никак не убиваются сессии?

[Dzen]

День добрый,

Не убиваются сессии, создаём сессию на первоначальной странице, после переходим на ту что вот ниже, и постоянно её перегружаем, раз в минуту, в пять и т.д., массив сессий постоянно жив почему-то

в htaccess
php_value session.gc_maxlifetime 1
php_value session.cookie_lifetime 0

в php файле что только не делал:

ini_set('session.gc_maxlifetime', 1);
ini_set('session.cookie_lifetime', 0);
ini_set('session.gc_divisor', 1);

session_set_cookie_params('0');
session_cache_expire(1);

session_start();

print_r($_SESSION);

в чём может быть косяк?

 

[artoodetoo]

А есть косяк? Что хочешь получить-то?

 

[Dzen]

думал что сессия прибьётся хотя бы за 24 часа на сервере, оказалось нет, авторизация работает.
Экспериментировал с параметрами чтобы сессия убилась через 5 секунд, ничего не убивается.
Убийство сессии хотел получить через 10 мин например, простым способом.

 

[Активист]

Эта вся херня не работает, особенно если локальные переменные ставите (работает только если на мемкеш захерачили хранение сессий). На линуксе файловые сессии чистятся через CRON, крон этот запускается раз в 30 минут. В Windows как помню (давно не запускал венду) файлы сессии хранятся до перезагрузки или вообще уй знает сколько (нужно настраивать планировщик венды).
root@home:/home/keeper# cat /etc/cron.d/php5
# /etc/cron.d/php5: crontab fragment for php5
# This purges session files in session.save_path older than X,
# where X is defined in seconds as the largest value of
# session.gc_maxlifetime from all your SAPI php.ini files
# or 24 minutes if not defined. The script triggers only
# when session.save_handler=files.
#
# WARNING: The scripts tries hard to honour all relevant
# session PHP options, but if you do something unusual
# you have to disable this script and take care of your
# sessions yourself.

# Look for and purge old sessions every 30 minutes
09,39 * * * * root [ -x /usr/lib/php5/sessionclean ] && /usr/lib/php5/sessionclean
root@home:/home/keeper#

 

[Dzen]

работает только если на мемкеш захерачили хранение сессий

это как?

На линуксе файловые сессии чистятся через CRON, крон этот запускается раз в 30 минут.

да уже 24 часа живут, там какие-то заморочки с гарбдеж клинер(garbage cleaner) и в дивизоре, и то вероятность - может очистит, а может и нет.

в общем сделал, так:
в переменной задаём время активности = 10 минут например
заносим это в сессию
и при каждом переходе по страницам, берём текущее время и смотрим не привысилось ли время внутри сессии, больше чем время активности в переменной
если больше, то убиваем сессию
не знаю насколько такие костыли верные

 

[Активист]

это как?
да уже 24 часа живут, там какие-то заморочки с гарбдеж клинер(garbage cleaner) и в дивизоре, и то вероятность - может очистит, а может и нет.
в общем сделал, так:
в переменной задаём время активности = 10 минут например
заносим это в сессию
и при каждом переходе по страницам, берём текущее время и смотрим не привысилось ли время внутри сессии, больше чем время активности в переменной
если больше, то убиваем сессию
не знаю насколько такие костыли верные

Если есть root, то поправте скрипт /etc/cron.d/php5, если нет, то добавьте от юзера. Можно что-то типа того:
*/5 * * * * find /var/www/username/tmp/ -type f -cmin +$(/usr/lib/php5/maxlifetime) -delete

 

[fixxxer]

На линуксе файловые сессии чистятся через CRON

Не на линуксе, а только в дебиане и производных, по дурной прихоти дебиановских мейнтенеров, с их извращенным пониманием слова "безопасность".

там какие-то заморочки с гарбдеж клинер(garbage cleaner) и в дивизоре, и то вероятность - может очистит, а может и нет

Из коробки работает так - с некоторой вероятностью, определяемой ini-настройками session.gc_probability и session.gc_divisor, php проходится по каталогу с сессиями и зачищает старье. У тебя gc_probability = 0 - потому это не проихойдёт никогда.

Также, разумеется, чтобы это работало, надо, чтобы у php были права на листинг директории с сессиями. Дебиановские мейнтенеры, упоротые по псевдобезопасности и рассматривающие как основной редкий идиотский кейс, когда shared-хостинг работает на чистом дебиане (ололо), снимают с каталога с сессиями право на чтение листинга (дескать, иначе сосед по хостингу сможет прочитать чужие сессии), и пихают gc_probability=0 и свой дурной крон. Это, конечно, полный бред: на шаред хостинге надо настраивать отдельный session.save_path для каждого клиента, как и запуск его php под отдельным пользователем.

 

[Активист]

это как?

http://php.net/manual/ru/memcached.sessions.php

 

[Активист]

Не на линуксе, а только в дебиане и производных, по дурной прихоти дебиановских мейнтенеров, с их извращенным пониманием слова "безопасность"

Ок)) С другими дистрами не очень. А как другие это все юзают? Через крон или иначе?

 

[fixxxer]

Ок)) С другими дистрами не очень. А как другие это все юзают? Через крон или иначе?

Все остальные просто не трогают умолчальные настройки php, и не пытаются заранее универсально решить проблему доступа к файлам сессий "соседом по шареду", полагая, что у системного администратора есть свои мозги - и работает стандартный механизм php с зачисткой директории с сессиями с некоторой вероятностью.

 

[Dzen]

У тебя gc_probability = 0 - потому это не проихойдёт никогда.

а так поможет?
ini_set('session.gc_probability', 1);

тогда значение этого Local Value становится 1, но Master Value 0

на шаред хостинге надо настраивать отдельный session.save_path для каждого клиента, как и запуск его php под отдельным пользователем.

могу свою директорию у себя сделать session_save_path, и кроном чистить, это будет верным? ну тоже костыли какие-то

 

[Активист]

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

 

[fixxxer]

а так поможет?

Поможет это прописать в php.ini. ini_set уже поздно.

 

[Dzen]

Поможет это прописать в php.ini. ini_set уже поздно.

туда доступа нема

htaccess тоже нет?

 

[fixxxer]

Тогда пинай того, у кого есть - у него руки из задницы. Видимо, снес крон (или поменял session.save_path, так что крон чистит уже не то), а настройки дебиановские - которые рассчитаны на запись сессий строго в тот путь, который чистит крон, и наличие этого самого крона - оставил.

 

[Активист]

туда доступа нема

htaccess тоже нет?

Попробуйте session.gc_probability = 1 ; session.gc_divisor = 1; session.gc_maxlifetime = 1; должен чистить сразу

 

[Активист]

Да, проверил, чистит сразу (session.save_path заменил, что бы небыло ошибки 13, нет доступа).

ini_set("error_reporting", E_ALL);
ini_set("display_errors", "on");

ini_set("session.gc_divisor", 1);
ini_set("session.gc_probability", 1);
ini_set("session.gc_maxlifetime", 2);
ini_set("session.save_path", "/tmp/");


session_start();

//$_SESSION['hello'] = "world";

var_dump( $_SESSION['hello']  );

 

[Dzen]

откуда почистило? прям отсюда? ini_set("session.save_path", "/tmp/");

 

[Активист]

откуда почистило? прям отсюда? ini_set("session.save_path", "/tmp/");

Угу. Дк, проверьте. Возмите мой скрипт, запустите первый раз без закоментированного $_SESSION['hello'] = "world"; а потом закоментируйте и запустите еще раз.

 

[Активист]

А вообще, лучше сувать tmp файлы куда-нибудь не в /tmp, а более защищенную директорию внутри директории пользователя.