AntiForgery vs. PartialCache

[c9mb]

Umbraco Forms requires the use of Html.AntiForgeryToken() inside the form, presumably so a hidden field with the request verification token can be matched against the session cookie token.

This is all fine and well except that it won't play nice with PartialCache use, where the form may well be cached, and I see lots of people struggling with this one - PartialCache or AntiForgeryToken - pick one.

We have a fairly typical environment where admins can add forms to pages on an ad-hoc basis, and those pages are largely cached for performance, so it becomes unpredictable when the antiforgery token will get cached, and then break the submit validation.

You can add Html.AntiForgeryToken() to a designated non-cached section of a page, and the hidden field and cookie tokens will be added, but Umbraco-Forms will only work with it being a hidden form-field, and throws an error if it's not included in the form. i.e. you need to include Html.AntiForgeryToken() inside the form, which immediately causes a problem if the form has been cached.

It would be nice of you could tell the form to find and use the hidden token field on the page, rather than just assume the hidden form-field, and point it to something you know is not cached, while allowing the form itself to be cached.

[nul800sebastiaan]

Sure, I am not entirely sure as to how much we can do for different caching strategies, we'll have to investigate.

[c9mb]

WARNING - some simplistic assumptions may follow.

My understanding is that the Asp.Net AntiForgergy works by comparing a token returned by the form against a key stored in a cookie.

However, Asp.Net does not seem to be be explicit about where the token comes from, just that it must be a valid token for the session key.

The default process that Umbraco forms uses for this is for the developer to insert the Html.AntiForgeryToken() call after initiating the Html.BeginUmbracoForm<>() wrapper.

Obviously, this makes it simple for the form to return the hidden field, and have the token verified, but equally obvious is that it breaks if the form is part of cached content.

However, there is no reason I can see why the token could not be fetched at run-time from a known cache-safe section of the page, provided the form scripts knew what to do and where to look, and I've seen (non-Umbraco) examples of this where devs are creating forms by ajax and creating a verification-token field this way, and it apparently works.

Perhaps an alternative Umbraco-Forms utility something like: Html.AntiForgeryTokenFromSelector("selector") that can be used by the dev instead of Html.AntiForgeryToken()

This could essentially insert the hidden field to be used for the token into the form, and include a simple client script do a basic document.querySelector(selector) to search for the first-descendant-or-self that contains the hidden input-field with the name "__RequestVerificationToken" and update the field value in the form.

That way, the developer can choose a cache-safe place to have the AntiForgeryToken injected into the page using Html.AntiForgeryToken() and have the Umbraco form fetch & return a valid token for the current key using that location.

[ronaldbarendse]

@c9mbundy The anti-forgery token needs to be within the form, as it must be POSTed to the controller that's handling the submit. Because this value is unique per visitor (cookie based), you can't cache the form and have this enabled. You can either use donut-caching to fix this or disable the anti-forgery token in Umbraco Forms: https://our.umbraco.com/documentation/add-ons/umbracoforms/Developer/Configuration/#enableantiforgerytoken.

[c9mb]

@ronaldbarendse Yes, a field with a token-value that works with the cookie key needs to be posted with the form, but the value of the field can be sourced from outside the form - I've seen this done elsewhere with Ajax-created forms - potentially allowing the token to be created in a cache-safe location, and a script accessing that location for the value to be returned with the form.

[c9mb]

Just giving this a gentle bump to see if there is any value in the suggestion above.
From what I've seen done elsewhere, if a utility script in the form was able to tell a form to fetch & load the current anti-forgery token from a known 'cache-safe' area of the page, then the form itself could be part of a partial-cache, and not fail due to the current issue with partial-cache and anti-forgery, where the cached anti-forgery token no longer matches the cookie token.

[umbrabot]

Hiya @c9mbundy,

Just wanted to let you know that we noticed that this issue got a bit stale and might not be relevant any more.

We will close this issue for now but we're happy to open it up again if you think it's still relevant (for example: it's a feature request that's not yet implemented, or it's a bug that's not yet been fixed).

To open it this issue up again, you can write @umbrabot still relevant in a new comment as the first line. It would be super helpful for us if on the next line you could let us know why you think it's still relevant.

For example:

@umbrabot still relevant
This bug can still be reproduced in version x.y.z

This will reopen the issue in the next few hours.

Thanks, from your friendly Umbraco GitHub bot 🤖 🙂

[c9mb]

@umbrabot still relevant

I think that there is still scope for an optional alternate to the 'traditional' method of inserting the Anti-Forgery token in-line as the form is being built, and instead all the token to be retrieved at client-runtime from a different location on the page. This could allow the page & form to be largely cached in partial-cache, while allowing the token to be inserted into a known uncached area so that it can be updated by each request.