Rails 4 authenticity_token с использованием нескольких серверов

Question

Что касается сессий в Rails с использованием CookieStore, если у меня есть два сервера с одинаковыми приложениями Rails и настроены одинаково (одинаковые для хэшей и конфигурации), я знаю, что если один пользователь попадает на первый сервер и запускает сеанс, а затем, если последующие запросы попадут на второй сервер, приложение будет работать нормально. Сейчас все в порядке.

Но, что касается форм и подлинности_token, как вы справляетесь с этим (предотвращая CSRF)?

Предположим, у меня есть хеш-сессия Cookie (с использованием CookieStore), которая хранится с использованием Cookies на стороне клиента (браузер). Таким образом, сеанс не используется на стороне сервера вообще.

Таким образом, если я создаю аутентификацию_token с сервера 1, а затем следующий запрос (POST из формы) попадает на сервер 2, запрос будет отклонен с ошибкой или исключение рельсов.

Как вы справляетесь с этим? Совместное использование подлинности_tokens в памяти или использование программного обеспечения «промежуточного программного обеспечения», например, для хранения значений ключа Redis, чтобы каждый сервер мог проверить подлинность_tokens?

Спасибо!

Answer 1

Начиная с Rails версии 4 Я вижу, что:.

«Если вы secret_key_base набор, ваши куки будут зашифрованы Это идет на шаг дальше, чем подписанными печенья в том, что зашифрованные куки не могут быть изменены или прочитанных пользователями. Это запуск по умолчанию в Rails 4. "

(Документация CookieStore, http://api.rubyonrails.org/classes/ActionDispatch/Session/CookieStore.html).

Итак, я думаю, что authenticity_token будет установлен в сеансе (Cookie-side), а затем будет отправлен в форму как скрытое поле, поэтому следующий запрос будет проверяться независимо от сервера (server1, server2 и т. Д. на). Таким образом, с помощью шифрования аутентичность_token не будет видна пользователям на стороне клиента. Без шифрования это можно увидеть и может быть проблемой безопасности.

Answer 2

В UsersController Вы можете использовать:

sign_in(@user, :bypass => true) 

из Devise::Controllers::SignInOut

В документации для этого мы можем прочитать:

Вход пользователя, который уже был аутентифицирован. Этот помощник полезен для регистрации пользователей после регистрации.

Все параметры, присвоенные sign_in, передаются методу set_user в смотрителе. Единственное исключение: опция обхода, которая обходит обратные вызовы начальника и хранит пользователя прямо в сеансе. Этот параметр полезен в случаях, когда пользователь уже зарегистрировался, но мы хотим обновить учетные данные в сеансе.

Примеры:

sign_in :user, @user      
sign_in(scope, resource) 
sign_in @user        
sign_in(resource) 
sign_in @user, event: :authentication 
sign_in(resource, options) 
sign_in @user, store: false    
sign_in(resource, options) 
sign_in @user, bypass: true    
sign_in(resource, options)