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

У меня есть приложение, которое использует для проверки подлинность. Rails 3 на рубине 1.9.2, с пассажиром на вершине nginx.

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

Может ли кто-нибудь дать мне предложения о том, где и как это может произойти?

Update:

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

ОБНОВЛЕНИЕ 2

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

Похоже, это может быть проблема с пассажирами? Но что более важно, как это происходит? Это серьезная проблема REAL. Как мне положить конец этому?

ОБНОВЛЕНИЕ 3

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

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

Обновление 4

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

Ответ 1

Я готов поспорить, что вы используете интеллектуальный нерестит Пассажира (по умолчанию) и становитесь жертвой Нерест Gotcha.

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

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

Ответ 2

Очень вероятно, что эта ошибка может быть исправлена путем обновления до кэша в стойке 1,2 или выше. Это может произойти:

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

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

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

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

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

Йоханнес