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

Question

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

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

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

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

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

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

Сессия:

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

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

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

---

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

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

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

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

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

Ничего не работает. Единственное, что работает, заключается в том, чтобы пользователь очистил свои файлы cookie на стороне клиента.

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

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

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

Спасибо!

Answer 1

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

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

[Существует потенциальное обходное решение, использующее CURL.] Работа с завитками будет выполнять простой запрос GET каждому из ваших mogrels на сервере, чтобы заправить их так, чтобы говорить. Вы можете сделать это с помощью capistrano, но это не сработает, если вы развернете его через панель управления. Вы можете найти короткий раздел Deploy крючками мы построили в инфраструктуру здесь: https://cloud-support.engineyard.com/faqs/overview/getting-started-with-engine-yard-cloud

Добавление простого запуска завиток http://localhost:500x>/DEV/нуль должен работать (где х порт у вас есть 5000-50005 на вашем тока настроить).

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

Answer 2

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

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

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

config.action_controller.allow_forgery_protection = false 

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

skip_before_filter :verify_authenticity_token 

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

protect_from_forgery :except => :index 

Замечания: ActionController::RequestForgeryProtection::ClassMethods docs Для более подробной информации

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 будет генерировать ключ для вас, которые затем могут быть вставлены в конфигурацию.

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

Answer 4

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

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

Answer 5

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

Cheers!

Answer 6

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

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

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

Answer 7

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

https://rails.lighthouseapp.com/projects/8994-ruby-on-rails/tickets/4690-mongrel-doesnt-work-with-rails-238#ticket-4690-37 Опубликовано Mike Бетани 30 августа 2010 @ 06:43 PM.