Rails - неверный токен подлинности после развертывания

Question

Мы используем EngineYard Cloud для развертывания нашего приложения Ruby on Rails. Мы работаем с Rails v2.3.3.

EngineYard Cloud развертывается на экземплярах AWS аналогично Capistrano. После каждого развертывания мы сталкиваемся с ошибками Invalid Authenticity Token. В частности, любой пользователь, который ранее посещал наше приложение, а затем посещает после развертывания и затем пытается отправить форму, получает ошибку токена неверной аутентификации. Эта ошибка сохраняется, пока они не сбросят свои куки для сайта. После сброса файлов cookie сайт работает, как и ожидалось, без ошибок.

Мы используем хранилище сеансов ActiveRecord, и сеансы сохраняются в базе данных.

Это ошибка, которую мы видим:

ActionController :: InvalidAuthenticityToken /usr/lib/ruby/gems/1.8/gems/actionpack-2.3.3/lib/action_controller/request_forgery_protection.rb:79:in `verify_authenticity_token '

Объект сеанса после развертывания равен nil, однако данные сеанса все еще сохраняются в базе данных, а cookie идентификатора сеанса все еще существует:

Сессия:

• идентификатор сессии: ноль
• данные: ноль

Мы не смогли объяснить это. Любые мысли о том, что может быть основной причиной?

Спасибо за любые предложения!

---

РЕДАКТИРОВАТЬ: просто чтобы обновить это, мы смогли выделить пример ошибки.

1) Форма загрузки пользователя 2) Код обновляется на сервере 3) Пользователь отправляет форму ** Ошибка неверного токена подлинности

Похоже, что при изменении среды Rails не может справиться с этим с помощью маркера аутентичности.

Мы попытались решить несколько шагов:

• Сброс сеанса
• Удаление cookie сессии (как в JavaScript, так и в Rails)
• Стирание таблицы сеансов в базе данных после развертывания кода

Ничего не работает. Единственное, что работает, - это чтобы пользователь удалил свои куки на стороне клиента.

(Мы гуглили (даже пробовали Binging!) За ответы, но не играли в кости. Похоже, похожая проблема: http://railsforum.com/viewtopic.php?id=21479)

Кроме того: изначально мы думали, что это было связано с нашим развертыванием в EngineYard, но мы также смогли воспроизвести его на нашем сервере разработки, на котором мы развертываем через Capistrano.

Любые мысли будут с благодарностью приняты.

Спасибо!

Answer 1

ОТВЕТ: После обширной работы EngineYard (они потрясающие!) Они смогли диагностировать проблему. Основной причиной этой проблемы является ошибка с кластерами беспородных. Монгрел, похоже, не видит первый пост-запрос после запуска. EngineYard проделал большую работу по диагностике этого:

Похоже, что в вашем коде нет ничего, что могло бы вызвать проблему, и я нашел людей вне нашей среды, которые тоже столкнулись с этой ошибкой (http://www.thought -scope.com / 2009/07 / mongrelcluster -rails-23x-плохо-post.html ). Я полагаю, что многие люди этого не видят, потому что первый запрос к сайту, как правило, не является постом, или они считают это случайностью.

[Существует потенциальный обходной путь, использующий CURL.] Для обхода локонов можно было бы выполнить простой GET-запрос к каждому из ваших дворняжек на сервере, чтобы, так сказать, заправить их. Вы можете сделать это с Capistrano, но это не сработает, если вы развернете через панель управления. Вы можете найти краткий раздел о хуках развертывания, которые мы встроили в инфраструктуру, здесь: https://cloud -support.engineyard.com / FAQs / Обзор / получение стартером-с двигателем-ярд облако

Добавление простого запуска curl http://localhost:500x> / dev / null должно работать (где x - это порт, который у вас есть 5000-50005 в текущей настройке).

Мы решили эту проблему, переключив наш стек с Mongrel на Passenger, но, очевидно, исправление для Mongrel находится в разработке. Надеюсь, это поможет кому-то, кто видит такую ​​же странную проблему.

Answer 2

Маркер подлинности - это скрытое поле в форме, которое проверяет, когда форма отправляется, чтобы убедиться, что данные публикации поступают из живого сеанса.

Это мера безопасности, запрещающая злоумышленникам использовать форму, отправляемую на их сайт, чтобы сказать действие по удалению чьей-либо учетной записи.

Вы можете отключить его во всем приложении, добавив его в config/environment.rb

config.action_controller.allow_forgery_protection = false

Вы можете выключить его с помощью

skip_before_filter :verify_authenticity_token

или включите его

protect_from_forgery :except => :index

проверьте ActionController :: RequestForgeryProtection :: ClassMethods документы для получения более подробной информации

Answer 3

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

У вас есть параметр конфигурации config.action_controller.session, установленный где-нибудь, и если вы это сделаете, есть ли что-то, что могло бы изменить его при повторном развертывании?

В одном из моих приложений он настроен в config/environment.rb, а в более новом (созданном с Rails 2.3) он установлен в config/initializers/session_store.rb. Настройка выглядит так:

config.action_controller.session = {
    :secret      => 'long-string-of-hex-digits'
  }

Если вы по какой-то причине не настроили это, rake secret сгенерирует для вас ключ, который затем можно будет вставить в вашу конфигурацию.

(Если это - & mdash; и оно не изменяется вашими процессами развертывания & mdash; тогда я понятия не имею, что происходит.)

Answer 4

Это решило эту проблему для меня :-) :-): -)

https://rails.lighthouseapp.com/projects/8994-ruby-on-rails/tickets/4690-mongrel-doesnt-work-with-rails-238#ticket-4690-37 Автор: Майк Бетани 30 августа 2010 года @ 06:43 вечера.

Answer 5

С такой же проблемой столкнулись Rails 2.3 и кластер Mongrel, в котором секрет сеанса определенно установлен в инициализаторе сеанса. Проблема возникла даже после очистки клиентских файлов cookie на клиенте.

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

Единственная добавленная информация, которую я могу предоставить, - это использование Apache mod_proxy_balancer вместе с https перед нашими Mongrels, однако эта проблема возникала до того, как мы включили SSL. Кто-нибудь видит это с haproxy в качестве балансировщика вместо Apache?

Answer 6

Если бы это было только для дворняжек! Я получаю точно такую ​​же ошибку и для пассажира (пользователь загружает форму, развертывает, отправляет -> неверный токен аутентификации). Было бы интересно узнать, как вы решили проблему, переключившись на пассажира? Любые дальнейшие советы приветствуются. Я тоже посмотрю поближе ...

Ура!

Answer 7

Я никогда не пытался выяснить детали, но для меня это проблема гнили данных на стороне клиента. Если я возился с тем, как я храню свои сессии (и, следовательно, мои данные авторизации), я время от времени получаю эту ошибку. Очистка личных данных браузера; куки, аутентифицированные сессии, работы, всегда решали это для меня.

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