У меня эта проблема на моем сайте, которая преследует меня в течение нескольких месяцев. Я продолжаю обойти это, но теперь я, похоже, не могу найти такой способ, поэтому я решил, почему не решить проблему с корнем?
Моя основная проблема заключается в том, что иногда (не всегда) данные сеанса исчезают для некоторых моих пользователей. Я знаю, что большинство из них наверняка имеют файлы cookie. Я подумал, что, возможно, это истекает, но я не думаю, что это так. Я установил окончание срока действия очень долго, плюс количество пользователей, которых их сеанс стирается, слишком чертовски высок …
Я использую drupal 6.
Какие-либо предложения?
Мало того, что вы можете проверить
Добавьте ob_start() и session_start(); в верхней части вашего скрипта.
Я думаю, ваша проблема связана с сеансом сохранения пути
Создайте папку с именем (chmod 777 MUST) в корневом каталоге, где находится .php, и поместите этот код
if(!is_writable(session_save_path())){ session_save_path(dirname(__FILE__)."/<xyz>"); }
Перед началом сеанса.
И еще одно, что происходит, когда ваш параметр сеанса используется для использования файлов вместо памяти.
У меня была аналогичная проблема, потому что это знаменитый www.
Сайт был доступен для доступа через веб-сайт http://www.example.com и example.com, который работал нормально, пока пользователь не ударил ссылку, которая была жестко запрограммирована с именем домена oposit. Затем он переключил домен / поддомен, а apache / php создал новый сеанс для пользователя в «новом» домене. Особенно это раздражало, когда люди возвращались с оплаты.
Решение в нашем случае состояло в том, чтобы всегда заставить пользователей использовать только example.com и либо отключать, либо перенаправлять все запросы на http://www.example.com прямо на example.com. Таким образом, вы никогда не получаете сессий на обоих.
Я слышал о проблеме session_regenerate_id () Drupal с определенной версией PHP. Не могли бы вы отключить эту функцию и проверить ее?
Я немного догадываюсь, я думаю, что это может быть ваша проблема / решение:
Короткий ответ: попробуйте установить session.cookie_lifetime в sites / default / settings.php на 0.
Длительный ответ: сеанс зависит от данных сеанса на сервере и файла cookie сеанса PHP на клиенте. Если вы установили слишком низкий срок службы cookie сеанса (по умолчанию Drupal составляет 23 дня, поэтому обычно это не проблема), сеанс может быть эффективно «уничтожен» на стороне клиента (браузером, удаляющим файл cookie, поскольку он истек).
Я столкнулся с этой проблемой за один раз, потому что я изменил время работы cookie сеанса Drupal с 23 дней до более низкого, что казалось более «подходящим», чтобы ограничить продолжительность входа в систему по соображениям безопасности. Но снижение продолжительности сеанса cookie не является решением. Лучший способ сделать это – ограничить продолжительность сеанса на стороне сервера. Вы можете сделать это, установив session.gc_maxlifetime (также в настройках Drupal) примерно на 7200 (в течение 2 часов). Затем вам нужно только убедиться, что сборка мусора сеанса выполняется достаточно часто, так что сеансы надежно завершаются через 2 часа.
Затем, чтобы избежать проблем с удалением файлов cookie на стороне клиента, вы можете установить session.cookie_lifetime равным 0. Это позволит убедиться, что, пока пользователь находится на веб-сайте, он будет выходить из системы, если он останется неактивным дольше чем session.gc_maxlifetime. И вдобавок к этому он также будет ЗАПИСАТЬ ПОЛЬЗОВАТЕЛЯ, когда он ЗАКРЫВАЕТ БРАУЗЕР. Это не сделано Drupal по умолчанию!
ОСНОВНОЕ ОБНОВЛЕНИЕ: Почему рекомендуется устанавливать время работы cookie в 0? Поскольку в противном случае СЕРВЕР устанавливает ДАТУ / ВРЕМЯ, когда клиенту требуется EXPIRE cookie. Так что, вы могли бы сказать? Хорошо, рассмотрите эту ситуацию: если у КЛИЕНТА УСТРАНЯТСЯ ЧАСЫ НЕПРАВИЛЬНО (да, это действительно так, даже если большинство компьютеров обновляют свое время через NTP, некоторые не делают) !! Это может закончиться печеньем гораздо раньше, чем вы думаете, ДАЖЕ ПРИНЯТИЕ ПРИБЫТИЯ. Это была точная проблема, которую мне пришлось отлаживать однажды …
Так что попробуйте время жизни cookie 0, по крайней мере, ONCE, если вы столкнетесь с странными проблемами сессии 🙂