Rails / Doorkeeper: Can't verify CSRF token authenticity - ruby-on-rails

I'm using Rails 3.2 with Doorkeeper gem for providing OAuth 2 API for 3rd party. I keep getting this warning when using my REST API from outside of the app:
WARNING: Can't verify CSRF token authenticity
The client app successfully authenticated via OAuth2. Why do I get this warning, and how to implement this csrf properly for the external API?

Remove protect_from_forgery from your ApplicationController (or remove it for calls to the API).

Turn off CSRF protection only for the controller that you want open ... this is safer than removing protect_from_forgery from the ApplicationController. In this case I'm using the create action as an example ... though you can modify to suit your needs.
class MessagesController < ApplicationController
protect_from_forgery with: :null_session, only: [:create]
# doorkeeper_for :create
end
Uncomment the doorkeeper line if you are authentication via doorkeeper.
The point is to open up only what needs to be opened up ...

Related

I have an Rails APP API with Doorkeeper OAuth2 client_credentials. How to get bearer token information within the controller?

I have an Rails APP API with Doorkeeper OAuth2 client_credentials. I want to get the token information within the controller and get the uid of the user who consumed the bearer token and send a logger.info to the logs. Seeking your suggestions / ideas in mind
I'm̀ not sure if I understood your question correctly but I'll try my best here.
Once you set up your doorkeeper configuration a helper method called doorkeeper_token will be available in your controller.
This method returns a Doorkeeper::AccessToken instance and should have the proper resource owner and application for the issued token.
If you are using the client credentials flow, your issued token will only contain an application_id but no resource_owner_id (as the resource owner is your user).
To have a resource owner a token has to be issued by the resource owner password credentials flow.
As for the log, you could have a before_action in your application_controller (or whatever base controller you use) that calls a method or simply a proc to log the token information:
before_action :log_token_info
def log_token_info
# log user name or whatever attribute you wish
# for the user id you can simply access the doorkeeper.resource_owner_id
logger.info "Token resource owner: #{doorkeeper.resource_owner.name}"
end
Same goes for the application related to the token

How do I solve InvalidAuthenticityToken error from Postman?

I'm running postman to send requests to my rails server. I am facing authenticity token issues when sending POST requests to create new objects. I need to be able to send all requests across the server and add the necessary authentications to a Postman environment.
If you're creating an API and want to accept requests from other domains you'll need to disable this security filter.
To do it add this to your controller :
skip_before_action :verify_authenticity_token, only: :your_post_action
You can disable it only for json requests, see this answer: https://stackoverflow.com/a/22715175/8352929

Devise 401 unauthorized only when the application is accessed over https

Scenario : I am working on a rails application in which our user is redirected to a third party application during payment request. Once it is done, we get the response back from that application via HTTP POST method. We have a controller action to handle that request but there is a before_action devise gem method 'authenticate_user!' for checking if the user is logged in.
Issue : when the application is accessed over https, the before_action check fails and the user is logged out of the application (Completed 401 Unauthorized). In case of http, it is fine.
Rails version : 4.2.6
Devise version : 3.5.6
I have not worked on devise much. Please let me know if you have any insights on this.
look to the token authentication.
for example you can assign to before_action a method wich check if user it's authenticated by token and this token keep in params when you make first request to payemnt application.
This is one example, you can make other scenario using token.

skip verify authenticity token vs protect from forgery with null session?

I'm building a Rails app that needs to receive POST'd emails from Mailgun. All OK, I have a controller and routes for that.
All requests receives HTTP 422 because Rails says Invalid Authenticity Token, which is really expected in this case.
I won't use rack-cors because I only allow Mailgun proceeding requests authenticating with its own signature mechanism.
Here my question: Should I use skip_before_action :verify_authenticity_token or should I use protect_from_forgery with: :null_session?
I ended up using protect_from_forgery with: :null_session as it won't contaminate any existing session.

rails 4 resets session on every request in production

I am implementing web app using rails 4.2.0 and ruby 2.2.0 and facing problem that any time request in done new session is set. In that case I cannot save anything to session since it's gone. Also that leads to situation that authenticity token cannot be checked.
For testing purpose forgery protection is disabled in ApplicationController, so that's not reason why session is reset.
class ApplicationController < ActionController::Base
#protect_from_forgery with: :null_session
skip_before_action :verify_authenticity_token `
end
I am using active record store to save session, but same happens for cookie store:
MyApp::Application.config.session_store :active_record_store, :key => '_myapp_session', domain: :all, tld_length: 2
Every time request is done new entry to sessions table is inserted with new sessions_id and session cookie in browser points to new session.
Any ideas what could reset session?
This happens only in production environment. In development everything is fine.
Your issue is due to the call to skip_before_action :verify_authenticity_token; if the authenticity token is not verified, Rails will reset the session. You also want to re-enable protect_from_forgery.
I've also seen AJAX requests without an authenticity token to cause the session to reset, again more detail here: http://www.kalzumeus.com/2011/11/17/i-saw-an-extremely-subtle-bug-today-and-i-just-have-to-tell-someone/
Ref: https://stackoverflow.com/a/11943243/449342

Resources