Question

Consider an ASP.NET MVC application using the Salt parameter in the [ValidateAntiForgeryToken] directive.

The scenario is such that the app will be used by many customers. It’s not terribly desirable to have the Salt known at compile time.

The current strategy is to locate the Salt value in the web.config.

[ValidateAntiForgeryToken(Salt = Config.AppSalt)]
//Config.AppSalt is a static property that reads the web.config.

This leads to a compile-time exception suggesting that the Salt must be a const at compile time.

An attribute argument must be a constant expression, typeof expression or array creation expression of an attribute parameter type

How can I modify the application to allow for a runtime loading of the Salt so that the app doesn’t have to be re-salted and recompiled for each customer?

Consider that the Salt won’t change frequently, if at all, thereby removing the possibility of invalidating form

Answer 1

I had the requirement to have different salts for different customers. In this case, I used Dixin’s solution for injecting the salt at runtime.

Anti Forgery Request Recipes For ASP.NET MVC and AJAX at the section titled “Specify non-constant salt in runtime“.

Decorate your Controllers with a new attribute:

[ValidateAntiForgeryTokenWrapper(HttpVerbs.Post)]
public class ProductController : Controller
{     
    // Only HTTP POST requests are validated.
}

This new attribute is defined as:

public class ValidateAntiForgeryTokenWrapperAttribute : FilterAttribute, IAuthorizationFilter
{
    public ValidateAntiForgeryTokenWrapperAttribute(HttpVerbs verbs)
    {
        this._verbs = new AcceptVerbsAttribute(verbs);
        this._validator = new ValidateAntiForgeryTokenAttribute()
            {
                //load from web.config or anywhere else
                Salt = Configurations.AntiForgeryTokenSalt
            };
    }

    // Other members.
}