Использование:
$date = date('m/d/Y h:i:s a', time());
Это работает.
Каждый раз, когда вызывается session_start , обновляется временная метка файлов сеанса (если она существует), которая используется для вычисления, если было превышено session.gc_maxlifetime.
Подробнее что важно, вы не можете зависеть от истечения срока действия сеанса после истечения времени session.gc_maxlifetime.
PHP запускает сборку мусора в сеансах с истекшим сроком действия после загрузки текущего сеанса и, используя session.gc_probability и session.gc_divisor , вычисляет вероятность запуска сборки мусора. По умолчанию вероятность составляет 1%.
Если у вас мало посетителей, существует вероятность того, что неактивный пользователь сможет получить доступ к сеансу, срок действия которого истек и который должен был быть удален. Если это важно для вас, вам нужно будет сохранить временную метку в сеансе и вычислить, в каком журнале пользователь был неактивен.
Этот пример заменяет session_start и применяет тайм-аут:
function my_session_start($timeout = 1440) {
ini_set('session.gc_maxlifetime', $timeout);
session_start();
if (isset($_SESSION['timeout_idle']) && $_SESSION['timeout_idle'] < time()) {
session_destroy();
session_start();
session_regenerate_id();
$_SESSION = array();
}
$_SESSION['timeout_idle'] = time() + $timeout;
}
session.gc_maxlifetime основывается на времени последнего изменения файла сеанса. Таким образом, каждый раз, когда файл сеанса изменяется или вызывается session_start () на отдельной странице, обратный отсчет до gc_maxlifetime начинается заново, и пользователь остается «авторизованным». Это та ценность, которую вы ищете. Вы можете изменить это с помощью ini_set () в своих файлах php или отредактировать php.ini, если у вас есть к нему доступ
session_cache_expire () управляет только заголовком HTTP «Expires». Этот заголовок определяет, как долго загруженное содержимое страницы остается в кеше браузера пользователя.
Некоторое время я искал хороший ответ на вопрос, как настройки сервера php.ini делают сеансы истекают. Я нашел много информации, но потребовалось время, чтобы понять, почему настройки работают так же, как и они. Если вы похожи на меня, это может быть вам полезно:
Сессии хранятся как файлы cookie (файлы на клиентском компьютере) или на стороне сервера как файлы на сервере. У обоих методов есть преимущества и недостатки.
Для сеансов, хранящихся на сервере, используются три переменные.
session.gc_probability session.gc_divisor session.gc_maxlifetime
(session.gc_probability / session.gc_divisor) дает вероятность того, что Будет запущена процедура сборки мусора. Когда сборщик мусора запускается, он проверяет файлы сеанса, к которым не обращались как минимум session.gc_maxlifetime и удаляет их.
Все это довольно хорошо объясняется в сообщениях на форуме (особенно в этом!) - Но возникают следующие вопросы:
1.) Как применяется эта вероятность? Когда сервер бросает кости?
A: Сервер бросает кости каждый раз, когда вызывается session_start () во время любой активный сеанс на сервере. Значит, вы должны увидеть мусор сборщик запускается примерно один раз из каждых 100 раз, когда вызывается session_start () если у вас установлено значение по умолчанию session.gc_probability = 1 и session.gc_divisor = 100
2.) Что происходит на серверах с низким объемом?
A: Когда вызывается session_start (), он ПЕРВЫМ обновляет сеанс и выполняет доступные вам значения сеанса. Это обновит время в файле сеанса на сервер. Он ТОГДА бросает кости и, если он выигрывает (шанс 1 из 100), он вызывает сборщик мусора. Затем сборщик мусора проверяет все файлы идентификаторов сеансов и видит, есть ли любые, которые могут быть удалены.
Это означает, что если вы единственный человек на сервере, ваш сеанс будет никогда не становитесь неактивными, и будет казаться, что изменение настроек не имеет эффект. Допустим, вы изменили session.gc_maxlifetime на 10 и session.gc_probability до 100. Это означает, что существует 100% вероятность того, что сборщик мусора запустится и удалит все файлы сеанса, к которым не обращались в течение последних 10 секунд.
Если вы единственный на сервере, ваш сеанс не будет удален. Тебе нужно запущен хотя бы 1 другой активный сеанс, чтобы ваш стал неактивным.
В общем, на сервере с небольшим объемом или с низким объемом - это может быть МНОГОЕ дольше, чем session.gc_maxlifetime перед запуском сборщика мусора и сеансы фактически удалены. И не зная, как это работает, это может кажутся вам совершенно случайными.
3.) Почему они используют вероятность?
A: Производительность. На сервере с большим объемом вам не нужен сборщик мусора выполняется по каждому запросу session_start (). Это замедлит сервер напрасно. Поэтому, в зависимости от объема вашего сервера, вы можете увеличить или уменьшить вероятность запуска сборщика мусора.
Я надеюсь, что это свяжет для вас все вместе. Если ты похож на меня, и ты пробовал session.gc_maxlifetime, и это не сработало (потому что вы пробовали на сервере разработки, чтобы никого не беспокоить), то этот пост Надеюсь, вы избавили вас от головной боли.
Удачи!