Form tokens are ignored when `csrf_meta_tags` is present about rails

[rafaelfranca]

This is expected behavior to allow applications to cache the form

[rbclark]

Do you mind providing a bit more information on this? I'm not sure I understand the connection to caching here since as far as I understand it the token in the form doesn't expire until the session expires, unless you are talking about caching the rendering of the form for multiple users? More importantly it seems like this behavior defeats the purpose of per_form_csrf_tokens since the lack of a per_form_csrf_token falls back to the token that csrf_meta_tags sets in the header.

In my case I don't cache the form so having the ability to force the form authenticity would be beneficial.

[rbclark]

After doing a bit more reading I'm convinced this is still an issue. Looking at the ActionView::Helpers::CsrfHelper docs it states that You don’t need to use these tags for regular forms as they generate their own hidden fields.. So the issue I am running into is that I am using regular forms but since I need csrf_meta_tags for a few places then all of the forms in my app end up using csrf_meta_tags instead of only validating against the per_form_csrf_tag.

[rafaelfranca]

Yes. I mean caching the same fork for multiple users using techniques like Russian doll caching. It indeed defeats the per_form_csrf tokens, but at the same time this is how the system was build. Per form tokens were added later, and even when they were added we kept checking the global token as well for compatibility issues.

We can't change this without breaking a lot of applications, that is why it isn't an issue. If you don't want the global tokens to make request legit, you can remove the global csrf_meta_tags from the template and only add to the few places you need it.

[rbclark]

Thank you for the clarification! The one issue I would run into with removing csrf_meta_tags globally is that I have some pages that have both types of forms on them. Being able to set protect_from_forgery strict: true or something along those lines and then relaxing it for the routes that need it would be immensely useful. Would you consider a PR for such a change? strict would of course default to false to maintain backwards compatibility.