WARN - attack prevented by Rack::Protection::AuthenticityToken

[henry74]

Apologies in advance, but this may be due to my ignorance with Padrino but I've spent a fair amount of time trying to figure this and have failed miserably.

I generated a Padrino app using the built in generate command and I'm simply attempting to make a POST request to the controller using an ajax call.

I'm pretty familiar with Sinatra and Rails and I've been sticking to RESTful urls. I am very confused as to why it appears so difficult to make a simple POST call.

I'm sure this is related to a default setting in Padrino for security purposes, but I can't for the life of me, figure out where it is. I've tried the disable protection settings and various combinations of:

:protection => false
:csrf_protection => false

in the controller (e.g. post :payment, :csrf_protection => false do...end) and I can't get a simple POST request to make it through to the controller body due to the 403 forbidden error.

On the client side I'm using amplify js and my configuration is:
amplify.request.define("post-payment", "ajax", {
url : "/payment",
dataType : "json",
type : "POST",
});

The error in the javascript is debug window:
POST http://localhost:3777/payment 403 (Forbidden)

The error in the terminal is:
WARN - attack prevented by Rack::Protection::AuthenticityToken
DEBUG - POST (0.0037s) /payment - 403 Forbidden

I'm using the latest stable version of Chrome and this is all done on localhost.

Any help in debugging this would be greatly appreciated. I know this shouldn't be that difficult for a simple POST AJAX call.

Thanks,
Henry

[hooopo]

Is this ok?

  # config/apps.rb
  set :protection, true
  set :protect_from_csrf, true
  set :allow_disabled_csrf, true

  # controller
  post :payment, :csrf_protection => false  do
  end

[henry74]

Thank hooopo - that worked. I had added set :protect_from_csrf, false in my app.rb to get around it. Your solution is much better (and safer from what I can tell).

Can you point me where in the Padrino documentation I could find this for future reference?

This can be a big frustration for new people trying to use Padrino if it's not easy to find/resolve especially since this is in development mode.

Perhaps the powers that be would consider different defaults or defaults which would be changed for development mode.

[hooopo]

@henry74 I find the solution from the test case in Padrino source code 😄

[henry74]

Thanks :-)

[skade]

@henry74 I hope you are aware that this opens you up to CSRF attacks.

And yes, "simple AJAX calls" are not simple anymore.

[henry74]

I don't plan to turn it off in production. As I mentioned above (see - "Perhaps the powers that be would consider different defaults or defaults which would be changed for development mode.") , I'm prototyping and this is strictly for development mode. I haven't figure out how I can pass tokens to avoid the Forbidden 403 as it's not clearly documented anywhere on how I'm supposed to use this feature. (see: "Can you point me where in the Padrino documentation I could find this for future reference?")

This is why I was asking if it could be changed for development mode similar to the reloading capability. If the document was clear on how I can leave this setting on, quickly add the right inputs on the client-side, and continue prototyping that would be excellent.

After looking through the change log I see it was a new feature added in 0.11.0. For someone just learning to use Padrino, it was a day wasted trying to avoid the 403 error when running everything localhost. Documentation has been great so far, but I assume the documentation for the new feature is lagging.

Can you point me to the documentation on how I can use properly new feature?

Thanks,
Henry

[dariocravero]

I understand your frustration on the docs on this topic @henry74. I will enhance the JS helpers to support this as part of #1127 and write some docs about it too. :) In the mean time, ask any questions you may have. You can find me on IRC any time. Thanks for using Padrino!

[postmodern]

How would I disable CSRF protection in another Sinatra app that I use in the main Padrino app?

[henry74]

Thanks Dario - appreciate it!

[mattsouth]

I ran into this and "fixed" it by turning off csrf protection. Later, after reading more of the code in the generated admin section, I came to the conclusion that the issue was likely caused because I didnt use the form_tag helper in my template. This helper automatically adds a hidden authenticity token to the form and by using this, posts worked just fine for me - with csrf protection turned on.

[henry74]

In my situation I am using padrino as an API layer and passing JSON directly, so don't have access to the form tag.

[henry74]

Is the response in this url (http://www.randomactsofsentience.com/2013/06/the-dreaded-attack-prevented-by.html) the right way to handle this problem?

[postmodern]

How does rails handle this?

[henry74]

Good question - no clue. Any rails experts out there who can chime in?

[skade]

Rails adds meta-tags to the document and reads them using a custom JQuery script.

See #1127 for details.

On Jul 8, 2013, at 3:37 AM, Henry Hwangbo notifications@github.com wrote:

Good question - no clue. Any rails experts out there who can chime in?

—
Reply to this email directly or view it on GitHub.

[dariocravero]

Yeah, I'm owing you guys a patch here... Sorry about that, will do it as soon as possible.

BTW, if somebody is using AngularJs, here's a snippet to make Padrino work with it seamlessly, add it before every route or wherever you need it.

response.set_cookie(:'XSRF-TOKEN', value: (session[:csrf] ||= SecureRandom.hex(32)), expires: Time.now + 3600*24)

[henry74]

Should we re-open it until a patch is submitted to address this?

[dariocravero]

Yup @henry74, done!

[henry74]

@dariocravero Sorry to be a pest, but wondering if there was an ETA on this patch or a workaround?

[dariocravero]

@henry74 will do it this week without excuse. It's at the top of my list! :) Thanks for bringing it back. 👍

[ujifgc]

@henry74 can you check if the problem is resolved with #1379

[nesquena]

Anyone know if this is still a valid issue?

[dariocravero]

No @nesquena, it has already been fixed with #1379. Don't know why the Fixes #1127 and #1251. bit on my description closed it. :) Closing now! Thanks!