request.session['_csrf_token'] и метатег csrf_token не совпадают

Я реализовал чат в реальном времени с помощью веб-сокетов с Фэй в Rails 4.2.

Прямо сейчас я могу опубликовать сообщение на каналах, используя curl, например:

curl http://localhost:3000/faye -d message={"channel":"/mychannel", "data": "my message"}'

Чтобы предотвратить это, я следовал руководству http://faye.jcoglan.com/security/csrf.html

Но клиент всегда получал ошибку 401

[,…]
0: {id: "8l", channel: "/meta/handshake", error: "401::Access denied", successful: false, version: "1.0",…}
advice: {reconnect: "handshake"}
channel: "/meta/handshake"
error: "401::Access denied"
id: "8l"
successful: false
supportedConnectionTypes: ["long-polling", "cross-origin-long-polling", "callback-polling", "websocket", "eventsource",…]
version: "1.0"

Я также отлаживаю переменные токена внутри расширения CsrfProtection. Они всегда отличаются.

Started POST "/faye" for 127.0.0.1 at 2016-02-20 02:53:59 +0600
session_token: "nICoUB0sDiwmNqbRpr1kUM7LtyBybCiddThnZceU7UI="
message_token: "PO5gD5tPwVMZifrUCsk8xnJXUIRZkhOU/vQ+ujbmQAugbshfhmPPfz+/XAWsdFiWvJznpCv+OwmLzFnf8XKtSQ=="

Почему они отличаются и как реализовать защиту csrf?


ruby-on-rails websocket csrf faye
person mef_    schedule 19.02.2016    source источник

Ответы (1)


arrow_upward
0
arrow_downward

Может помочь метод из кода Rails: проверка

Идея: на странице у вас есть значение в кодировке Base64 и вам нужно его расшифровать

person faron    schedule 19.02.2016
comment
Оказалось, что документы Faye Security немного устарели. Как сказал @faron, на странице у меня есть закодированное в base64 значение токена csrf. Поэтому я просто добавил дополнительную логику для декодирования этой строки и сравнения с request.session['_csrf_token'] только после этого. - person mef_; 20.02.2016