Направляющие - недопустимый маркер подлинности после развертывается
man curl :
-H/--header
(HTTP) Extra header to use when getting a web page. You may specify
any number of extra headers. Note that if you should add a custom
header that has the same name as one of the internal ones curl would
use, your externally set header will be used instead of the internal
one. This allows you to make even trickier stuff than curl would
normally do. You should not replace internally set headers without
knowing perfectly well what you're doing. Remove an internal header
by giving a replacement without content on the right side of the
colon, as in: -H "Host:".
curl will make sure that each header you add/replace get sent with
the proper end of line marker, you should thus not add that as a
part of the header content: do not add newlines or carriage returns
they will only mess things up for you.
See also the -A/--user-agent and -e/--referer options.
This option can be used multiple times to add/replace/remove multi-
ple headers.
Пример:
curl --header "X-MyHeader: 123" www.google.com
Вы видите запрос, которые завихряются отправленные путем добавления -v опция.
6 ответов
ОТВЕТ: После обширной работы EngineYard (они потрясающие!) Они смогли диагностировать проблему. Основная причина этой проблемы - ошибка с кластерами беспородных. Похоже, что Mongrel не видит первый почтовый запрос после запуска. EngineYard проделал большую работу по диагностике этого:
Похоже, что в вашем коде нет ничего, что вызывает проблему, и я нашел людей за пределами нашей среды, которые также испытали ошибку ( http: // www .heret-scope.com / 2009/07 / mongrelcluster-rails-23x-bad-post.html ). Я полагаю, многие люди этого не видят, потому что первый запрос к сайту обычно не является постом, или они списывают его на случайность.
[Существует потенциальный обходной путь с использованием CURL.] Обход curl будет выполнять простой запрос GET к каждому из ваших дворняг на сервере, чтобы, так сказать, запустить их. Вы можете сделать это с помощью capistrano, но это не сработает, если вы развернете через панель управления. Вы можете найти небольшой раздел о хуках развертывания, которые мы встроили в инфраструктуру здесь: https://cloud-support.engineyard.com/faqs/overview/getting-started-with-engine-yard-cloud
Добавление простого выполнения curl http: // localhost: 500x > / dev / null должен работать (где x - это порт 5000-50005 в вашей текущей настройке).
Мы решили проблему, переключив наш стек с Mongrel на Passenger, но, по-видимому, исправление для Mongrel - в работах. Надеюсь, это поможет тому, кто видит ту же странную проблему.
Похоже, секретный ключ, используемый для аутентификации, меняется при повторном развертывании, что делает недействительными все существующие сеансы.
У вас есть параметр конфигурации 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 сгенерирует для вас ключ, который затем можно будет вставить в вашу конфигурацию.
(Если это так - и это не изменяется вашими процессами развертывания - тогда я понятия не имею, что происходит.
Токен аутентичности - это скрытое поле в форме, которое rails проверяет при отправке формы, чтобы убедиться, что почтовые данные поступают из живого сеанса.
Он используется в качестве безопасности мера для предотвращения использования злоумышленниками формы отправки на своем сайте, чтобы сказать действие удаления для чьей-либо учетной записи.
Вы можете отключить ее для всего приложения, добавив ее в config / environment.rb
config.action_controller.allow_forgery_protection = false
You можно выключить отдельный контроллер с помощью
skip_before_filter :verify_authenticity_token
или включить
protect_from_forgery :except => :index
. Дополнительные сведения см. в документации ActionController :: RequestForgeryProtection :: ClassMethods
Я никогда не вдавался в подробности, чтобы выяснить подробности, но для меня это проблема гниения данных на стороне клиента. Если я возился с тем, как я храню свои сеансы (и, следовательно, мои данные авторизации), я время от времени получаю эту ошибку. Очистка личных данных браузера; файлы cookie, аутентифицированные сеансы, работа всегда решали эту проблему для меня.
Надеюсь, это поможет.
Если бы только дворняги были! У меня такая же ошибка и у пассажира (пользователь загружает форму, развертывает, отправляет -> недействительный токен аутентификации). Было бы интересно узнать, как вы решили вопрос, перейдя на пассажирский? Любые дальнейшие подсказки приветствуются. Я тоже посмотрю поближе ...
Ура!
Вы столкнулись с той же проблемой с Rails 2.3 и кластером Mongrel, где секрет сеанса определенно установлен в инициализаторе сеанса. Проблема возникла даже после очистки клиентских файлов cookie на клиенте.
Однако предложение выполнить запрос curl get для всех дворняг после их перезапуска, похоже, работает - слава богу, кто-то понял это, потому что это выглядит чертовски неясным .
Единственная дополнительная информация, которую я могу предоставить, мы используем Apache mod_proxy_balancer вместе с https перед нашими Mongrels, однако эта проблема возникла до того, как мы включили SSL. Кто-нибудь видит это с haproxy в качестве балансировщика вместо Apache?