Вы должны установить собственный тайм-аут сеанса. Оба параметра, упомянутые другими ( session.gc_maxlifetime и session.cookie_lifetime ), не являются надежными. Я объясню причины этого.
First:
session.gc_maxlifetime
session.gc_maxlifetime указывает количество секунд, по истечении которых данные будут считаться «мусором» и очищаться. Сборка мусора происходит во время начала сеанса.
Но сборщик мусора запускается только с вероятностью session.gc_probability , деленной на session.gc_divisor . При использовании значений по умолчанию для этих параметров (1 и 100 соответственно) вероятность составляет всего 1%.
Ну, вы можете просто настроить эти значения так, чтобы сборщик мусора запускался чаще. Но когда сборщик мусора запускается, он будет проверять правильность каждого зарегистрированного сеанса. И это требует больших затрат.
Кроме того, при использовании PHP по умолчанию session.save_handler файлов данные сеанса сохраняются в файлах по пути, указанному в session.save_path . С этим обработчиком сеанса возраст данных сеанса вычисляется по дате последнего изменения файла, а не по дате последнего доступа:
Примечание: Если вы используете обработчик сеансов на основе файлов по умолчанию, ваша файловая система должна отслеживать время доступа (atime). Windows FAT этого не делает, поэтому вам придется искать другой способ сбора мусора во время сеанса, если вы застряли в файловой системе FAT или любой другой файловой системе, в которой недоступно отслеживание времени. Начиная с PHP 4.2.3 он использовал mtime (дату изменения) вместо atime. Таким образом, у вас не будет проблем с файловыми системами, в которых недоступно отслеживание времени.
Таким образом, может также случиться, что файл данных сеанса будет удален, в то время как сам сеанс все еще считается действительным, поскольку данные сеанса не были недавно обновлены.
И второй:
session.cookie_lifetime
session.cookie_lifetime указывает время жизни куки в секундах, которое отправляется в браузер. [...]
Да, все верно. Это влияет только на время жизни куки, и сам сеанс все еще может быть действительным. Но задачей сервера является недействительность сеанса, а не клиента. Так что это ничего не помогает. Фактически, если для session.cookie_lifetime установлено значение 0
, файл cookie сеанса станет настоящим файлом cookie сеанса , который действителен только до закрытия браузера.
Вывод / лучшее решение:
Лучшее решение - установить собственное время ожидания сеанса. Используйте простую временную метку, которая обозначает время последней активности (т.е. запрос), и обновляйте ее при каждом запросе:
if (isset($_SESSION['LAST_ACTIVITY']) && (time() - $_SESSION['LAST_ACTIVITY'] > 1800)) {
// last request was more than 30 minutes ago
session_unset(); // unset $_SESSION variable for the run-time
session_destroy(); // destroy session data in storage
}
$_SESSION['LAST_ACTIVITY'] = time(); // update last activity time stamp
Обновление данных сеанса с каждым запросом также изменяет дату изменения файла сеанса, чтобы сессия не удалялась сборщиком мусора преждевременно.
Вы также можете использовать дополнительную метку времени для периодической регенерации идентификатора сеанса, чтобы избежать атак на такие сеансы, как фиксация сеанса :
if (!isset($_SESSION['CREATED'])) {
$_SESSION['CREATED'] = time();
} else if (time() - $_SESSION['CREATED'] > 1800) {
// session started more than 30 minutes ago
session_regenerate_id(true); // change session ID for the current session and invalidate old session ID
$_SESSION['CREATED'] = time(); // update creation time
}
Примечания:
session.gc_maxlifetime
должно быть как минимум равно времени жизни этого пользовательского обработчика срока действия (1800 в этом примере);
- если вы хотите прекратить сеанс через 30 минут активности вместо 30 минут с момента запуска , вам также нужно будет использовать
setcookie
с истечением time()+60*30
чтобы сохранить файл cookie сеанса активным.