Html.AntiForgeryToken() writes nothing on second call

[justdmitry]

When having several forms in one Razor view - antiforgery token is written only to first one.

View:

<form id="form-one">
    @Html.AntiForgeryToken()
</form>
<form id="form-two">
    @Html.AntiForgeryToken()
</form>

Generated html:

<form id="form-one">
    <input name="__RequestVerificationToken" type="hidden" value="CfDJ8..." />
</form>
<form id="form-two">

</form>

But second form should (expected) also include hidden input with (same?) token!

Checked on 1.0.0 RTM bits.

[justdmitry]

Workaround: save generated token to variable and write this variable multiple times.

@{
    var token = Html.AntiForgeryToken();
}
<form id="form-one">
    @token
</form>
<form id="form-two">
    @token
</form>

Crosspost: http://stackoverflow.com/questions/37511452

[dougbu]

@justdmitry this looks like what might happen if the RenderAtEndOfFormTagHelper were disabled. Enable that and your original code should be fine. As-is, nothing notices one <form> has ended and another begun.

In your _ViewImports.cshtml:

@addTagHelper *, Microsoft.AspNetCore.Mvc.TagHelpers

or

@addTagHelper Microsoft.AspNetCore.Mvc.TagHelpers.RenderAtEndOfFormTagHelper, Microsoft.AspNetCore.Mvc.TagHelpers

[justdmitry]

@dougbu you're right, I have no any tag helpers in my code.

But IMHO it seems a little wrong that behavior of one feature (IHtmlGenerator) silently(!) depends on existence of other feature (activated Tag Helper). Maybe DefaultHtmlGenerator should check if taghelper is active (e.g. FormContext may have a bool IsInsideOfForm), and do not be "smart" outside of "smart environment"?

[dougbu]

@justdmitry your approach might work though more code to detect when other features are not being used seems odd.

Another approach would be to register the RenderAtEndOfFormTagHelper by default -- similar to the UrlResolutionTagHelper. I vaguely thought this was already the case.

A few other features depend on a per-<form> FormContext. Makes me curious what other features (e.g. addition of HTML attributes for client-side validation) are a bit broken in the "multiple <form>s in a view that are not associated with tag helpers or generated by HTML helpers" case.

On the other hand, ASP.NET Core MVC actually creates unique FormContext instances more than in earlier releases

On the links between MVC features, that's a tough row to hoe. For example, tag and HTML helpers generate names the model binding system understands.

[dougbu]

After a quick chat here, realize the correct fix is to change DefaultHtmlGenerator.GenerateAntiforgery() to always generate the token if !FormContext.CanRenderAtEndOfForm. That'll make Html.AntiForgeryToken() behave as it did in MVC 5 when inside a bare <form> element. Will also ensure the <form> tag helper works correctly when used multiple times on a page while the RenderAtEndOfFormTagHelper is not enabled.

[justdmitry]

more code to detect when other features are not being used seems odd

Correct way is to detect that other features are being used and enable additional intelligence only in that case. Otherwise, silly generate more and more hidden inputs if requested.

Registering some more tag helpers by default is not a good idea - that's extra fat for brilliant reborn/newborn framework.

You added new comment while I was writing this one... Yes, it looks like a good solution.

[dougbu]

Cleared Investigate label and assignee since investigation is done.