Commits
-------

753c067 [FrameworkBundle] added $view['form']->csrfToken() helper
e1aced8 [Twig] added {{ csrf_token() }} helper

Discussion
----------

[Twig] [FrameworkBundle] added CSRF token helper

I've added a templating helper and Twig function for generating a CSRF token without the overhead of creating a form.

```html+jinja
<form action="{{ path('user_delete', { 'id': user.id }) }}" method="post">
    <input type="hidden" name="_method" value="delete">
    <input type="hidden" name="_token" value="{{ csrf_token('delete_user_' ~ user.id) }}">
    <button type="submit">delete</button>
</form>
```

```php
<?php

class UserController extends Controller
{
    public function delete(User $user, Request $request)
    {
        $csrfProvider = $this->get('form.csrf_provider');
        if (!$csrfProvider->isCsrfTokenValid('delete_user_'.$user->getId(), $request->request->get('_token')) {
            throw new RuntimeException('CSRF attack detected.');
        }

        // etc...
    }
}
```

The test that is failing on Travis appears to be unrelated, but I may be wrong?

```
1) Symfony\Bundle\SecurityBundle\Tests\Functional\LocalizedRoutesAsPathTest::testLoginLogoutProcedure with data set #1 ('de')
RuntimeException: OUTPUT:
Catchable fatal error: Argument 3 passed to Symfony\Bundle\FrameworkBundle\Controller\TraceableControllerResolver::__construct() must be an instance of Symfony\Component\HttpKernel\Debug\Stopwatch, instance of Symfony\Bundle\FrameworkBundle\Controller\ControllerNameParser given, called in /tmp/2.1.0-DEV/StandardFormLogin/cache/securitybundletest/appSecuritybundletestDebugProjectContainer.php on line 94 and defined in /home/vagrant/builds/kriswallsmith/symfony/src/Symfony/Bundle/FrameworkBundle/Controller/TraceableControllerResolver.php on line 37
```

---------------------------------------------------------------------------

by pablodip at 2012-01-10T14:18:45Z

As you don't need forms to use the csrf provider, how about putting its service without the form prefix? It could even make sense to put the CsrfProvider as a component since you can use it standalone and in more cases than only forms. It would be a small component though.

---------------------------------------------------------------------------

by Tobion at 2012-01-10T17:54:14Z

I think it would be more clear to generate the token in the controller. Doing so in the template will spread the CSRF intention across template and controller. So I don't think this extension is necessary.

---------------------------------------------------------------------------

by kriswallsmith at 2012-01-10T17:58:14Z

@pablodip I'm open to the idea of a Csrf component. This would be a good place for some nonce classes as well.

@Tobion I disagree. One use case is for a list of users, each with a delete form. Iterating over the users in the controller and generating a token for each, just to iterate over them again in the view is a waste and adds complexity.

---------------------------------------------------------------------------

by Tobion at 2012-01-10T18:05:14Z

I see. But I don't understand why the intention needs to be different for each user to delete. Usually the intention is the same for each form type. I thought this is enough.

---------------------------------------------------------------------------

by kriswallsmith at 2012-01-10T18:06:13Z

Yes, a static intention would suffice.

---------------------------------------------------------------------------

by Tobion at 2012-01-10T18:07:08Z

Then your use case is not valid anymore.

---------------------------------------------------------------------------

by Tobion at 2012-01-10T18:12:25Z

I would suggest to make a cookbook article out of it about how to create a simple form without the form component.
And include such things as validating the result using the validator component and checking the CSRF.

---------------------------------------------------------------------------

by kriswallsmith at 2012-01-10T21:32:50Z

This helper makes it easier to use CSRF protection without a form and we should make it as easy as possible. Spreading the intention across controller and template is not concerning to me. Either way, a cookbook entry is a great idea.

---------------------------------------------------------------------------

by Tobion at 2012-01-10T21:47:12Z

Well, it's just one line more without this helper. So I disagree it makes it really easier when you know how to use the CsrfProvider which is a pre-condition anyway since you must still validate its correctness by hand.

---------------------------------------------------------------------------

by kriswallsmith at 2012-01-13T13:24:15Z

Another use case is when rendering a page with a bunch of simple buttons with different intentions: delete user, delete comment, follow, unfollow... Creating all of these in the controller just leads to spaghetti.

---------------------------------------------------------------------------

by jwage at 2012-01-17T21:55:53Z

:+1: lots of use cases for something like this @opensky