2013-09-13 3 views
1

У нас есть веб-приложения, которые только что вышли в эфир. Поскольку это используется в нескольких корпоративных сетях, возникла своеобразная проблема.Конфигурация Codeigniter за прокси

Пользователи могут войти в систему, но пользователи, которые находятся за корпоративными сетями, периодически регистрируются и просматривают другие профили пользователей как свои собственные. Иногда сеансы сталкиваются.

Это текущие настройки на сервере:

$config['sess_cookie_name']  = 'cisession'; 
$config['sess_expiration']  = 72000; 
$config['sess_expire_on_close'] = FALSE; 
$config['sess_encrypt_cookie'] = FALSE; 
$config['sess_use_database'] = FALSE; 
$config['sess_table_name']  = 'ci_sessions'; 
$config['sess_match_ip']  = FALSE; 
$config['sess_match_useragent'] = TRUE; 
$config['sess_time_to_update'] = 300; 

Мы на Амазонке позади балансировки нагрузки на стеке ЛАМПЫ.

Мы действительно тянем за волосы на этом, любые указатели приветствуются. Благодаря!

+0

Возможно, вы захотите спросить на http://serverfault.com/ и включить информацию о том, что такое топология (прокси и т. Д.) С обеих сторон. Это похоже на проблему на сетевом уровне, а не на программную проблему. Быстрый поиск в Google поднял http://aws.amazon.com/about-aws/whats-new/2010/04/08/support-for-session-stickiness-in-astic-load-balancing/, в котором говорится о липких сессий. В принципе, если вы используете балансировщик нагрузки с несколькими серверами позади него, должен быть механизм «привязать» сеанс к серверу, который запустил сеанс. – stormdrain

+0

Проблема происходит по крайней мере в 4 таких типах сетей, поэтому я бы исключал это на данном этапе. Также вступает в игру липкий сеанс, поэтому одни и те же пользователи используют один и тот же экземпляр сервера на амазонке. Предположите, что у вас есть время, но я думаю, что это что-то в приложении и обработке сеанса, что вызывает это. – codeHead

+0

Да, было бы разумно, что это происходит в разных сетях, если сеансы не являются липкими; нет ничего, что говорило бы балансировочному серверу, на который сервер отправил запрос. Таким образом, пользователь 1 запускает сеанс на сервере 1; пользователь 2 запускает сеанс на сервере 2; следующий запрос пользователя 1 переходит на сервер 2 и получает сеанс пользователя 2. Если вы не внесли никаких других изменений в сеансы codeigniters, codeigniter НЕ является проблемой, иначе эта проблема появится для всех, кто использует CI. – stormdrain

ответ

1

Я не знаю, разрешит ли это решение для вас, но у меня были проблемы с двумя клиентами, которые находились за прокси-сервером, который ограничивал размер заголовков HTTP. Обычно это не проблема, однако в обработчике сеансов Codeigniters есть ошибка, она записывает новую запись cookies: для каждой переменной сеанса, вместо того, чтобы делать все за один раз. Это приводит к тому, что заголовки HTTP становятся раздутыми и могут вызывать проблемы в некоторых сетях, если у вас много переменных сеанса.

Мой совет: загрузить Live HTTP Headers для Firefox и проверить заголовки вашего сайта на страницах, используя сеанс. Если вы найдете несколько записей для cookies:, это может вызвать проблемы.

Чтобы решить эту проблему, я бы рекомендовал использовать вашу собственную библиотеку сеансов. Дайте Dariusz Debowczyk's Session Class попробовать и посмотреть, что произойдет. Он исправил это для меня.

Другой альтернативой было бы обратиться к сетевому администратору, чтобы проверить, какой тип прокси они используют (некоторые более старые версии прокси-сервера squid дали мне проблемы с сеансом codeigniters), и если они устанавливают ограничения на размер заголовков HTTP.

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