Add 'protect_from_forgery` to turn on Rail's built-in protection.

Since the Doorkeeper controllers inherit from Doorkeeper::Application (which inherits directly from ActionController::Base) and not ApplicationController, they never call `protect_from_forgery`, which means that non-GET methods don’t validate CSRF tokens. Thus, it’s possible for an attacker to host a form on an arbitrary URL, and if a users is logged into a site that uses Doorkeeper visits the URL, the attacker can grant access to a application on that site.
Good question, testing for this is a bit messy. This stub is really only
for Rails3, to give it a similar behavior to Rails4.

A few options:
* The simplest test might be to stub an expectation that
`protect_from_forgery` is called on Doorkeeper::ApplicationController. *
There's a protected method `protect_from_forgery?` that we could check.
* Instead of stubbing the handle method, assert that it's called.

Let me know what you'd prefer!

On Tuesday, December 9, 2014, Tute Costa <notifications@github.com> wrote:

> In spec/requests/endpoints/authorization_spec.rb:
>
> > +
> > +  context 'forgery protection enabled' do
> > +    before do
> > +      ActionController::Base.allow_forgery_protection = true
> > +    end
> > +
> > +    after do
> > +      ActionController::Base.allow_forgery_protection = false
> > +    end
> > +
> > +    background do
> > +      create_resource_owner
> > +      sign_in
> > +      # Ensure compatiblity between Rails 3 and Rails 4 in handling CSRF failure
> > +      ActionController::Base.any_instance.stub(:handle_unverified_request).
> > +        and_raise(ActionController::InvalidAuthenticityToken)
>
> Is there a way to test this without stubbing the system under test?
>
> —
> Reply to this email directly or view it on GitHub
> <https://github.com/doorkeeper-gem/doorkeeper/pull/516/files#r21507279>.
>