Это то, что мой init.php
Похоже, что загружается по всему сайту:
$suid = 0;
session_set_cookie_params(60, '/', '.' . $_SERVER['HTTP_HOST'], true);
session_save_path(getcwd() . '/a/');
if (!isset($_SESSION['id'])) {
session_start(['cookie_lifetime' => 60]);
$_SESSION['id'] = session_id();
$_SESSION['start'] = date('d_m_Y_H_i');
$_SESSION['ip'] = $_SERVER['REMOTE_ADDR'];
} elseif (isset($_SESSION['uid'])) {
$suid = $_SESSION['uid'];
}
В настоящее время я тестирую сессии PHP, поэтому я просто установил 60 секунд как время жизни.
Мне было интересно, почему были созданы сеансы, так как никто еще не знает домен, поэтому я добавил ip
, Я посмотрел это и выяснил это:
Так что это был бот Google Crawler. Поскольку существует больше поисковых систем и ботов, я не хочу сохранять эти обходы в моих файлах сеансов и заполнять этим свое пространство.
Итак, мои вопросы:
1) Даже после окончания срока действия теста (60 секунд) файл сеанса остается в пользовательском каталоге. Я прочитал это потому, что я установил пользовательский каталог. Это правда?
2) Какой эффективный способ удалить все неиспользуемые / просроченные файлы сеанса? Должен ли я добавить $_SESSION['last_activity']
с отметкой времени, и пусть cronjob заглянет в мой пользовательский каталог, получит данные файла сеанса и рассчитает истекшие сеансы, чтобы удалить его?
3) Должен ли я избегать сохранения ненужных сессий теми бот-сканерами, которые просто ищут строку «бот» внутри $_SERVER['HTTP_HOST']
или есть лучший способ идентифицировать «нечеловеческих посетителей» / сканеров?
Я также ценю любые улучшения / предложения в моем коде в верхней части. Я просто вызвал некоторые Internal Server Error
ранее, потому что session_start()
был призван часто, насколько я могу судить по php-fpm-slow
-logs.
1) Даже после окончания срока действия теста (60 секунд) файл сеанса остается в пользовательском каталоге. Я прочитал это потому, что я установил пользовательский каталог. Это правда?
Нет, пользовательский каталог выбирает сеансовый GC, и файлы будут очищены. Это просто не происходит сразу.
2) Какой эффективный способ удалить все неиспользуемые / просроченные файлы сеанса? Должен ли я добавить
$_SESSION['last_activity']
с отметкой времени, и пусть cronjob заглянет в мой пользовательский каталог, получит данные файла сеанса и рассчитает истекшие сеансы, чтобы удалить его?
PHP 7.1 имеет session_gc (), который вы можете позвонить из cronjob и он сделает все необходимое.
В старых версиях PHP вы полагаетесь на основанный на вероятности GC по умолчанию, где очистки выполняются случайным образом.
Это может быть не особенно эффективно, но это были единственные универсальные решения на протяжении более десяти лет, так что …
тем не мение, если на вашем сервере запущен Debian, скорее всего, session.gc_probability установлен в 0
и использование специфичного для Debian скрипта crontab для регулярной очистки — у вас будут проблемы с пользовательским каталогом в этом случае, и есть несколько вариантов:
getcwd().'/a/'
Я бы сказал, что каталог сессий по умолчанию в Debian почти наверняка является более безопасным местом, поэтому он объективно будет лучше.$_SESSION['last_activity']
даже не годится для этого; время доступа к файлу / время изменения, предоставляемое самой файловой системой.3) Должен ли я избегать сохранения ненужных сессий теми бот-сканерами, которые просто ищут строку «бот» внутри
$_SERVER['HTTP_HOST']
или есть лучший способ идентифицировать «нечеловеческих посетителей» / сканеров?
Ты думаешь о $_SERVER['HTTP_USER_AGENT']
но нет — это не решение проблемы.
Малоизвестный (или в значительной степени игнорируемый для удобства), но единственный способ сделать это правильно — никогда не начинать сеанс перед входом.
Раздражение сканеров, запускающих бесполезные файлы сеансов, — проблема пренебрежимая; реальная проблема заключается в способности решительного злоумышленника заполнить хранилище сеансов, использовать все возможные идентификаторы сеансов, избегать session.use_strict_mode
— ни одна из этих атак не может быть легко осуществлена, но может привести к DoS или фиксации сеанса, поэтому они не должны быть легко отклонены как возможности.
Постскриптум Бонусный совет: не используйте $_SERVER['HTTP_HOST']
— это пользовательский ввод из HTTP Host
заголовок; в этом случае это может быть безопасно из-за того, как работают куки, но в целом этого следует избегать.
Этот cronjob уже существует (см. 1.) — наиболее эффективный способ — сохранить данные сеанса в memcached вместо простых файлов из-за использования памяти и TTL.
Вы должны избегать сравнения строк с пользовательскими агентами или хостами, потому что это ненадежно, HTTP_HOST
это имя вашего локального хоста, а не имя удаленного хоста, и наиболее существенная причина, по которой вы не должны делать ничего другого для бота Google: вы имитируете поведение веб-сайта, которое очень плохо сказывается на вашем рейтинге Google. Добро пожаловать в Google, как и любой другой посетитель сайта.