#402 request_forgery_protection_token should be set at ActionController::Base load time - Ruby on Rails

Type	To find
responsible:me	tickets assigned to you
tagged:"@high"	tickets tagged @high
milestone:next	tickets in the upcoming milestone
state:invalid	tickets with the state invalid
created:"last week"	tickets created last week
sort:number, importance, updated	tickets sorted by #, importance or updated
Combine keywords for powerful searching.
Use advanced searching »

This project is archived and is in readonly mode.

#402 ✓wontfix

request_forgery_protection_token should be set at ActionController::Base load time

Reported by José Valim | June 12th, 2008 @ 01:14 PM

This is a small-tiny-patch but important one.

I have one controller, that logs-in users:

  class UsersController < ActionController::Base
    protect_from_forgery :only => :login

    def login
      ...
    end
  end

And I have another one, that shows my homepage:

  class ContentController < ActionController::Base
    def index
      ...
    end
  end

What happens is that my homepage has a form to login users quickly, but since request_forgery_protection_token is nil when my app loads, protect_against_forgery? returns false and the form doesn't have a authenticity_token field.

So, when the user fill the form, it will be sent to UsersController#login, that will call protect_from_forgery that will finally set request_forgery_protection_token.

But since no token was sent, it will raise a InvalidAutenticityToken error.

To fix this, we just have to set on ActionController::Base:

  @@request_forgery_protection_token = :authenticity_token

And while it's not released, I recommend to put the line above in your ApplicationController.

0001-request_forgery_protection_token-should-be-set-at-Ac.patch 965 Bytes

Comments and changes to this ticket

You flagged this item as spam.
Joe Noon June 13th, 2008 @ 12:46 AM
protect_from_forgery needs to be on the initiating page and the receiving page.
The error you are getting seems to be correct/desired to me, because you are not sending the token from your homepage.
José Valim June 13th, 2008 @ 01:03 AM
Your point of view is also interesting, but this is not what happens either.
When the request is sent to the UsersController, the request_forgery_protection_token is set, so the next attempts to login from the homepage WILL WORK, even with not requiring proctect_from_forgery in my controller.
The problem is that this is a very specific behaviour. Every time you start your server, only the first attemp to login from the homepage will fail, because in all other attempts, the authenticy_token will be correctly create since request_forgery_protection_token was set.
The actual implementation is just between what you said and what I'm saying.
I would recommend you to try this "bug" yourself. Try to "cross post" between your controllers using protect_from_forgery only in the receiver. The error will happen only on the first attempt.
You flagged this item as spam.
Hugo Barauna June 29th, 2008 @ 07:45 PM
- Tag set to “actionpack, bug, patch, request-forgery-protection”
This is a nice patch! So, I would like to know when it will be accepted.
Pratik July 4th, 2008 @ 02:09 AM
- State changed from “new” to “wontfix”
- Assigned user set to “Pratik”
This will cause protect_against_forgery? to always return true, which is not desired.
Simple fix for your problem would be :
- Preload UserController
- Include form_authenticity_token value manually in your form.
Thanks.