Сессии пересекаются.Рубин на рельсах

Question

У меня есть приложение, которое использует devise для аутентификации. Рельсы 3 на ruby ​​1.9.2, с пассажиром на вершине nginx.

Вот моя проблема: я заметил, что иногда мои сеансы пересекаются. Когда я вошел в систему как один пользователь, я иногда становлюсь другим пользователем. Это действительно ужасная проблема. Мне удалось заставить его остановиться, используя хранилище сессий active_record. Но я озадачен тем, где это могло произойти. Это происходит как при использовании cookie-хранилища, так и memcached хранилища. Я не уверен, с чего начать отладку. Я прошел весь мой код, и я только читаю из «current_user», а не пишу. У меня нет кода для хранения предметов в сессии.

Может ли кто-нибудь дать мне совет относительно того, где и как это может происходить?

Обновление:

Я установил div в верхней части страницы, чтобы выводить содержимое сеанса при каждом запросе. Это не просто переключение пользователей, это целый сеанс. Есть некоторые фиктивные переменные, которые я установил в сессии, чтобы посмотреть, что произойдет. Когда сеансы пересекаются, (пользователь A становится пользователем B), пользователь A теперь видит фиктивные переменные, которые имел пользователь B. И пользователь Б вышел из системы.

ОБНОВЛЕНИЕ 2

Я нашел еще один вопрос о переполнении стека, описывающий ту же самую проблему: В Rails, что может заставить пользователя иметь сеанс другого пользователя?

Похоже, это может быть проблема с пассажиром? Но что более важно, почему это происходит? Это РЕАЛЬНАЯ большая проблема. Как мне положить этому конец?

ОБНОВЛЕНИЕ 3

Сейчас я использую Unicorn для обслуживания своего приложения. Я установил config.threadsafe! и начал использовать исключительно сеансы активной записи. Больше нет сессий memcached. Проблема ушла. По крайней мере, я могу перестать вырывать волосы, потому что дыра в безопасности забита.

Я все еще хотел бы знать, что именно вызвало это. В большинстве уроков показано, как настроить пассажира с помощью метода порождения по умолчанию. Естественно, я думаю, что memcached лучше всего подойдет для управления сессиями по сравнению с другими методами. Особенно в среде с несколькими серверами приложений.

Обновление 4

Хорошо, последнее и последнее обновление. Это было проблемой с разветвленными процессами, использующими то же самое соединение memcached. Я исправил это, используя клиент dalli memcached и переустановив соединение в обратном вызове after_fork единорога или пассажира.

Answer 1

Я бы поспорил, что вы используете умное порождение Пассажира (по умолчанию) и становитесь жертвой Призыва Готча .

Установите ваш PassengerSpawnMethod на «консервативный» и посмотрите, исчезнет ли это. Это легко объясняет случай memcache, если только вы не защищаете его. Предположительно, похожая проблема в устройстве (или вашем коде).

Видите ли вы, что сеансы пересекаются на физических серверах или только на одном сервере?

Answer 2

Весьма вероятно, что эту ошибку можно исправить путем обновления до стоечного кэша 1.2 или выше. Вот что может происходить:

1. Пользователь А запрашивает страницу. Создается сеанс, и в ответе возвращается заголовок Set-Cookie.
2. Rack-cache неправильно кэширует заголовок Set-Cookie с идентификатором сеанса пользователя A.
3. Пользователь B запрашивает ту же страницу, а стойка-кеш обслуживает кэшированный ответ, включая заголовок Set-Cookie с идентификатором сеанса пользователя A.

Эти два билета обсуждают эту проблему: https://github.com/rails/rails/issues/476 и https://github.com/rtomayko/rack-cache/pull/52

Наконец, эта проблема упоминается в примечаниях к выпуску стойки кеш-памяти 1.2: https://github.com/rtomayko/rack-cache/blob/master/CHANGES

Также обратите внимание, что даже когда вы НЕ используете хранилище сеансов cookie, сеанс ID все еще сохраняется в cookie, поэтому эта ошибка может по-прежнему кусать вас, даже если вы не используете cookie магазин.

Надеюсь, это поможет.

Johannes