Is it possible to implement Rails csrf through cookie_store at the same while using ember-simple-auth Devise?
Guides like this one always deactivate Rails.application.config.session_store
which from my understanding does not allow Rails to keep track of csrf tokens which causes Rails to lose track of sessionsg. After attempting many solutions including:
require jquery_ujs
on Rails manifesto.Rails.application.config.session_store :disabled
.The end result is still pretty much the same:
Can't verify CSRF token authenticity followed by Completed 422 Unprocessable Entity if protect_from_forgery is set with :exception instead of :null_session.
Example Transaction:
Partial Request HEADER:
X-CSRF-Token:1vGIZ6MFV4kdJ0yYGFiDq54DV2RjEIaq57O05PSdNdLaqsXMzEGdQIOeSyAWG1bZ+dg7oI6I2xXaBABSOWQbrQ==
Responder HEADER
HTTP/1.1 422 Unprocessable Entity
Content-Type: text/plain; charset=utf-8
X-Request-Id: 71e94632-ad98-4b3f-97fb-e274a2ec1c7e
X-Runtime: 0.050747
Content-Length: 74162
The response also attaches the following:
Session dump
_csrf_token: "jFjdzKn/kodNnJM0DXLutMSsemidQxj7U/hrGmsD3DE="
The rails-csrf response from my csrf branch (branch has been deleted).
beforeModel() {
return this.csrf.fetchToken();
},
Partial dump of the return statement:
_result: Object
param: "authenticity_token"
token: "1vGIZ6MFV4kdJ0yYGFiDq54DV2RjEIaq57O05PSdNdLaqsXMzEGdQIOeSyAWG1bZ+dg7oI6I2xXaBABSOWQbrQ=="
From my understanding, all of these attempted solutions have the common root: session_store is disabled...
The idea here is to have two storages: A cookie-based storage only for the csrf token that is maintained by Rails, and a localStorage maintained by Ember-simple-auth where the user authenticity token, email and id are being taken care of while a custom session SessionAccount inherits those values and validates them against the server before setting the user that will be available for the entire Ember.js.
The validation by the SessionAccount occurs in order to detect any tampering with the localStorage. The validation occurs every time the SessionAccount queries the localStorage (e.g page reload) as it communicates with the server through a Token model (token, email and id.) The server responds with 200 or 404 through a TokenSerializer which only renders email or the validation error, thus not disclosing the frontend to see other authentication_tokens unless the user sign in through the login form which requires email and password.
From my understanding, the weak spots in this methodology are not susceptible enough to be so easily hackable unless:
Now onto the practical approach:
Rails.application.config.session_store :csrf_cookie_store, key: '_xxxxx_id', httponly: false
on the session_store.db. require 'csrf_cookie_store'
.protect_from_forgery with: :exception
on application.rb.