2015-07-18 6 views
0

Я работаю над старым приложением, которое использует CodeIgniter 2.1.3. Во время разработки он работает на vhost, доступном по адресу http://vhostname/app (что равно xampp/htdocs/project/app).Сессии CodeIgniter продолжают уничтожаться

Я скопировал живую систему 1: 1 в мою систему разработки (с базой данных и всем остальным).

Система использует сеансы для хранения временных данных для посетителей (например, тележки). Моя проблема: при моем развитии env сеанс уничтожается при каждом обновлении. После некоторого тестирования я нашел в том, что это происходит в system/core/Sessions.php:

 // encryption was not used, so we need to check the md5 hash 
     $hash = substr($session, strlen($session)-32); // get last 32 chars 
     $session = substr($session, 0, strlen($session)-32); 

     // Does the md5 hash match? This is to prevent manipulation of session data in userspace 
     if ($hash !== md5($session.$this->encryption_key)) 
     { 
      log_message('error', 'The session cookie data did not match what was expected. This could be a possible hacking attempt.'); 
      $this->sess_destroy(); 
      return FALSE; 
     } 

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

Единственное mentionable разница между живой и Девой системой:

  • На живой системе приложение встроено через IFRAME на WordPress установки. Таким образом, URL не http://vhost/app но http://projectname.com

Update: По крайней мере, я только что нашел причину, почему хэш не совпадает с ключом шифрования. Я включаю wp-head.php из WordPress, чтобы получить доступ к функциям WordPress. Но, похоже, мои сеансы «развратились» на данный момент - без включения сеанса в живую.

Обновление 2: Хорошо, мне кажется, я приближаюсь. Я попытался сравнить файлы cookie сеанса, один с включенной версией wordpress и без нее. Там на самом деле большая разница:

Печенье с WordPress в комплекте:

a:6:{s:10:\"session_id\";s:32:\"8e3b975d0b30f6b229f475b2f03947a0\";s:10:\"ip_address\";s:9:\"127.0.0.1\";s:10:\"user_agent\";[...] 

Без WordPress:

a:6:{s:10:"session_id";s:32:"7451cd27e1b45d2c7b8a042ed6b2bf9e";s:10:"ip_address";s:9:"127.0.0.1";s:10:"user_agent";[...] 

Где эти кавычки берутся?

Спасибо!

+0

Можете ли вы сообщить мне настройки сеанса в файле конфигурации, какой браузер вы используете? – shafiq

+0

См. Https://gist.github.com/nehalist/5df5f01e4a009fcebaf1 – nehalist

ответ

0

Проверьте настройки сеанса в конфигурационном файле

$config['sess_match_useragent'] = TRUE; 

Если sess_match_useragent установлен как верно. Затем сделайте его ложным и попробуйте.

Как CodeIgniter проверить каждый раз для UserAgent и возвращает его значение как

Mozilla/5.0 (Windows NT 5.1; rv:13.0a1) Gecko/20120206 Firefox/13.0a1 

ИЛИ

Mozilla/5.0 (Windows NT 5.1; rv:13.0a1) 

и проверить с куки. Некоторое время его обрезает user_agent и сохраняет в cookie, но сравнивается с полным возвращаемым значением, которое вызывает эту проблему.

Если вы используете базу данных для сохранения сеанса в codeingiter

$config['sess_cookie_name']  = 'ci_session'; 
$config['sess_expiration']  = 7200; 
$config['sess_expire_on_close'] = FALSE; 
$config['sess_encrypt_cookie'] = FALSE; 
$config['sess_use_database'] = TRUE; 
$config['sess_table_name']  = 'ci_sessions'; 
$config['sess_match_ip']  = FALSE; 
$config['sess_match_useragent'] = TRUE; 
$config['sess_time_to_update'] = 300; 
enter code here 

затем в CI_session увеличения длины столбца таблицы user_agent.

+0

Изменение конфигурации сеанса ничего не изменило. Я исправил это временно, добавив 'stripslashes' в функцию' sess_read', но изменение ядра не должно быть правильным решением, я думаю ... – nehalist

+0

Вы изменили $ config ['sess_match_useragent'] = TRUE; ЛОЖЬ? не меняют основную библиотеку. Если вы хотите изменить, то расширьте библиотеку – shafiq

Смежные вопросы