Обработка сессий PHP с несколькими интерфейсами
У нас есть 2x pfSense FW’s в HA, за этим, 2x Zen Load Balancers в Master / Slave Cluster, позади тех, 3x Front End веб-стека серверов работает NGinx, PHP-FPM, PHP-APC. В этом же сегменте сети есть 2x Сервера БД MySQL в репликации Master / Slave.
Сеансы PHP на внешних интерфейсах должны быть «очищены» через 1440 секунд:
session.gc_maxlifetime = 1440
.
Срок действия файлов cookie истекает, когда браузер пользователя закрывается:
session.cookie_lifetime = 0
Сегодня конечный пользователь получил уведомление о том, что он вошел в систему (форма входа на веб-сайте на основе PHP), но прошел проверку подлинности как совершенно другой пользователь. Это неудобно, если не сказать больше.
ZLB настроены на использование Hash: Sticky Client. Они должны привязывать пользователей к одному внешнему интерфейсу (FE) на время их сеанса. Единственная причина, по которой я могу думать об этом, заключается в том, что два из FE сгенерировали один и тот же ID Session ID, а затем как-то пользователю не повезло, и его LB направил к этому другому FE.
У меня много вопросов, но пока у меня есть только несколько:
- Могу ли я установить другое имя SESSID для сервера переднего плана? Остановит ли это генерацию идентификаторов сеанса FE, которые были одинаковыми? Это, по крайней мере, приведет к тому, что пользователь выйдет из системы, а не войдет снова как другой пользователь!
- Мы синхронизируем данные сайта, используя lsyncd и целую кучу процессов inotifywatch, но мы не синхронизируем каталоги / var / lib / php, которые содержат сеансы. Я сознательно не делал этого … Теперь я думаю, возможно, я должен синхронизировать это. lsyncd сможет дублировать файлы сессий на всех 3 интерфейсах в течение примерно 10 секунд после изменения сессий. Хорошая идея как временное исправление?
Наконец, я хорошо знаю, что клиент должен использовать БД для хранения сессий. Это полностью исключило бы возможность дублирования идентификаторов сеансов. Но прямо сейчас они не желают расставлять приоритеты во времени разработки.
Идеи очень приветствуются, так как я изо всех сил пытаюсь увидеть легкий выход, даже в качестве временной меры. Я не могу позволить другому клиенту войти в систему как другой пользователь. Это огромное нет-нет.
Спасибо!!
Решение
Судя по вашему вопросу, вы несколько озадачены этой проблемой — и неясно, какую именно проблему вы пытаетесь решить.
Сегодня мы были предупреждены конечным пользователем, что он вошел в систему (форма входа на основе PHP на веб-сайте), но был аутентифицирован как совершенно другой пользователь.
Здесь потенциально может происходить несколько вещей.
Срок действия файлов cookie истекает, когда браузер пользователя закрывается:
Не так. В зависимости от того, как настроен браузер, большинство из них сохранит сеансовые куки при перезапуске. Так как это контролируется на клиенте, это не то, с чем вы можете многое сделать.
Сеансы PHP на внешних интерфейсах должны быть «очищены» через 1440 секунд
Волшебное слово здесь «после» — сборка мусора запускается случайным образом. Файлы сессий могут сохраняться гораздо дольше, и дефолт Обработчик удачно извлечет и десериализует данные сеанса после истечения TTL.
Вы контролируете код приложения? (если нет, ваш пост здесь не по теме). Если это так, то возможно, что в вашем коде есть уязвимости фиксации сеанса и перехвата (но это основано на описании, предоставленном пользователем — которое обычно неточно и вводит в заблуждение).
Это также возможный этот контент кэшируется где-то в стеке ненадлежащим образом.
Вы не сказали, работает ли сайт по протоколу HTTP, HTTPS или смешанному, и если задействован HTTPS, где прекращается SSL. Это ключ к пониманию того, где может возникнуть проблема.
Ваши следующие шаги должны гарантировать, что:
-
в вашем коде есть функция выхода из системы, которая уничтожает данные сеанса а также меняет идентификатор сессии
-
что вы меняете идентификатор сессии при аутентификации
-
Ваши сценарии на основе сеанса возвращают соответствующую информацию о кэшировании (включая заголовок Varies: Cookie)
это высоко маловероятно, что две системы будут генерировать один и тот же идентификатор сеанса в одно и то же время.
На самом деле вы хотите избежать использования липких сессий. Это не трудно.
У тебя есть 2 слоя на вашем внешнем интерфейсе, которые не добавляют никакого функционального или производительного значения, а так как вы используете липкие сеансы, фактически нет никакого значения емкости или устойчивости !!! Кто бы ни продал вам это, смеется всю дорогу до банка.
Другие решения
Других решений пока нет …