Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Html.AntiForgeryToken - IIS classic pipeline incompatibility #162

Closed
ParanoidPenguin opened this issue May 16, 2018 · 6 comments
Closed
Assignees

Comments

@ParanoidPenguin
Copy link

I tried upgrading an old app from Microsoft.AspNet.Mvc 5.2.3 to 5.2.6 earlier today and encountered a System.PlatformNotSupportedException when calling Html.AntiForgeryToken(). "This operation requires IIS integrated pipeline mode".

This app is currently using Classic mode on a 2012 r2 server. Afraid the system is awkward to access for debugging/diagnostic etc (offline, remote site) so at the time I just had to just rollback to 5.2.3 (which works fine). Apologies I don't have more detailed info or a stack trace.

Thought I'd mention it in case it affects anyone. I guess this might have been introduced during the 5.2.4 change (Html.AntiForgeryToken() adds duplicate X-Frame-Options headers if called more than once) but I can't be certain.

@dougbu
Copy link
Member

dougbu commented May 29, 2018

@ParanoidPenguin thanks for reporting the issue. Any more information would be much appreciated.

In the meantime, I'll look at the details of the 5.2.4 release for anything overlapping the symptoms you describe.

@dougbu dougbu self-assigned this May 29, 2018
@icnocop
Copy link

icnocop commented Jun 6, 2018

I encountered this issue too when I updated the Microsoft.AspNet.Mvc NuGet package from 5.2.3 to 5.2.4.

Here's a copy of the YSOD from Windows Server 2016:
This operation requires IIS integrated pipeline mode.txt

Login.cshtml snippet:

@using (Html.BeginForm("Login", "Account", new { ReturnUrl = ViewBag.ReturnUrl }, FormMethod.Post, new { @class = "form-horizontal", role = "form" }))
{
    @Html.AntiForgeryToken() // Line 13
    <hr />
    @Html.ValidationSummary(true, "", new { @class = "text-danger" })

Stack Trace:

[PlatformNotSupportedException: This operation requires IIS integrated pipeline mode.]
   System.Web.HttpResponse.get_Headers() +174
   System.Web.HttpResponseWrapper.get_Headers() +10
   System.Web.Helpers.AntiXsrf.AntiForgeryWorker.GetFormInputElement(HttpContextBase httpContext) +112
   System.Web.Helpers.AntiForgery.GetHtml() +92
   System.Web.Mvc.HtmlHelper.AntiForgeryToken() +21
   ASP._Page_Views_Account_Login_cshtml.Execute() in c:\Program Files (x86)\Company\Application\WebRoot\Web\Views\Account\Login.cshtml:13
   System.Web.WebPages.WebPageBase.ExecutePageHierarchy() +197
   System.Web.Mvc.WebViewPage.ExecutePageHierarchy() +105
   System.Web.WebPages.StartPage.RunPage() +17
   System.Web.WebPages.StartPage.ExecutePageHierarchy() +73
   System.Web.WebPages.WebPageBase.ExecutePageHierarchy(WebPageContext pageContext, TextWriter writer, WebPageRenderingBase startPage) +78
   System.Web.Mvc.RazorView.RenderView(ViewContext viewContext, TextWriter writer, Object instance) +235
   System.Web.Mvc.BuildManagerCompiledView.Render(ViewContext viewContext, TextWriter writer) +107
   System.Web.Mvc.ViewResultBase.ExecuteResult(ControllerContext context) +291
   System.Web.Mvc.ControllerActionInvoker.InvokeActionResult(ControllerContext controllerContext, ActionResult actionResult) +13
   System.Web.Mvc.ControllerActionInvoker.InvokeActionResultFilterRecursive(IList`1 filters, Int32 filterIndex, ResultExecutingContext preContext, ControllerContext controllerContext, ActionResult actionResult) +56
   System.Web.Mvc.ControllerActionInvoker.InvokeActionResultFilterRecursive(IList`1 filters, Int32 filterIndex, ResultExecutingContext preContext, ControllerContext controllerContext, ActionResult actionResult) +420
   System.Web.Mvc.ControllerActionInvoker.InvokeActionResultWithFilters(ControllerContext controllerContext, IList`1 filters, ActionResult actionResult) +52
   System.Web.Mvc.Async.<>c__DisplayClass3_6.<BeginInvokeAction>b__3() +197
   System.Web.Mvc.Async.<>c__DisplayClass3_1.<BeginInvokeAction>b__5(IAsyncResult asyncResult) +100
   System.Web.Mvc.Async.WrappedAsyncResult`1.CallEndDelegate(IAsyncResult asyncResult) +10
   System.Web.Mvc.Async.WrappedAsyncResultBase`1.End() +49
   System.Web.Mvc.Async.AsyncControllerActionInvoker.EndInvokeAction(IAsyncResult asyncResult) +27
   System.Web.Mvc.<>c.<BeginExecuteCore>b__152_1(IAsyncResult asyncResult, ExecuteCoreState innerState) +11
   System.Web.Mvc.Async.WrappedAsyncVoid`1.CallEndDelegate(IAsyncResult asyncResult) +29
   System.Web.Mvc.Async.WrappedAsyncResultBase`1.End() +49
   System.Web.Mvc.Controller.EndExecuteCore(IAsyncResult asyncResult) +45
   System.Web.Mvc.<>c.<BeginExecute>b__151_2(IAsyncResult asyncResult, Controller controller) +13
   System.Web.Mvc.Async.WrappedAsyncVoid`1.CallEndDelegate(IAsyncResult asyncResult) +22
   System.Web.Mvc.Async.WrappedAsyncResultBase`1.End() +49
   System.Web.Mvc.Controller.EndExecute(IAsyncResult asyncResult) +26
   System.Web.Mvc.Controller.System.Web.Mvc.Async.IAsyncController.EndExecute(IAsyncResult asyncResult) +10
   System.Web.Mvc.<>c.<BeginProcessRequest>b__20_1(IAsyncResult asyncResult, ProcessRequestState innerState) +28
   System.Web.Mvc.Async.WrappedAsyncVoid`1.CallEndDelegate(IAsyncResult asyncResult) +29
   System.Web.Mvc.Async.WrappedAsyncResultBase`1.End() +49
   System.Web.Mvc.MvcHandler.EndProcessRequest(IAsyncResult asyncResult) +28
   System.Web.Mvc.MvcHandler.System.Web.IHttpAsyncHandler.EndProcessRequest(IAsyncResult result) +9
   System.Web.CallHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute() +549
   System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously) +157

Thank you.

Edit
I was still receiving the error even after downgrading the Microsoft.AspNet.Mvc NuGet package from 5.2.4 back to 5.2.3, and was only able to get it working again when I also downgraded the Microsoft.AspNet.Razor and Microsoft.AspNet.WebPages NuGet packages from 3.2.4 back to 3.2.3.

@dougbu
Copy link
Member

dougbu commented Jun 7, 2018

@icnocop thank-you for the additional information

@icnocop
Copy link

icnocop commented Jun 22, 2018

Here's a work-around:

In Global.asax.cs:

  1. Set AntiForgeryConfig.SuppressXFrameOptionsHeader = true; in Application_Start:
protected void Application_Start()
{
    // other code here, removed for brevity

    AntiForgeryConfig.SuppressXFrameOptionsHeader = true;
}
  1. Manually add the X-Frame-Options header in Application_BeginRequest:
protected void Application_BeginRequest(object sender, EventArgs e)
{
    HttpContext.Current.Response.AddHeader("X-Frame-Options", "SAMEORIGIN");
}

SimonCropp added a commit to approvals/ApprovalTests.Net.Asp that referenced this issue Aug 22, 2019
@mkArtakMSFT
Copy link
Member

Thanks for sharing the workaround, @icnocop.
Closing as we don't plan to do more here.

BenedekFarkas added a commit to OrchardCMS/Orchard that referenced this issue May 23, 2023
BenedekFarkas added a commit to OrchardCMS/Orchard that referenced this issue Jun 28, 2023
* Fixing that RecipeManagerTests failed due to HttpContext not being available

* Fixing OwnerEditor tests in CommonPartProviderTests as the owner editor now checks for a different permission since 5b0c82d

* Fixing typo in CommonPartProviderTests.UpdateModelStub class name

* Fixing that test cases for invalid path in FileSystemStorageProviderTests broke in a3e9bef (issue #6802, PR #6919)

I should review PRs more carefully!

* Fixing CurrentCultureWorkContextTests

* Fixing indentation in DefaultDateFormatterTests

* Updating Orchard.Azure.Web's required version of System.Web.Mvc to match the rest of the solution

* Orchard.Specs: Fixing assembly loading errors when starting up the web host by adding binding redirects

* Adding empty compile workflow from dev

* Adding the compile workflow's actual contents

* Changing default shell to pwsh (msbuild was not found in cmd?)

* Adding msbuild to PATH

* Removing unused references to System.Net.Http

* Replacing System.Net.Http references with its NuGet package to pin the correct version number (experimental)

* Upgrading Microsoft.CodeDom.Providers.DotNetCompilerPlatform to 4.1.0 (latest) to get rid of old System.Http.Net dependency

* Orchard.proj: Spec target actually depends on only the Compile target, not Package-Stage (experimental)

* Compile workflow: Testing the Test and Spec targets

* Fixing Test step

* Fixing compile workflow to also mark Razor compilation warnings as errors

* Restoring Orchard.Specs/Hosting/Orchard.Web/Web.config to match Orchard.Web's web.config closer

so that it loads assemblies from the Dependencies folder.
This fixes the error with Autofac not being able to resolve dependencies for DefaultOrchardShell

* Orchard.Specs/Hosting/Orchard.Web/Global.asax.cs: Workaround for AntiForgeryToken bug in ASP.NET MVC since version 5.2.4

aspnet/AspNetWebStack#162

* Revert "Replacing System.Net.Http references with its NuGet package to pin the correct version number (experimental)"

This reverts commit 087f284.

* Revert "Upgrading Microsoft.CodeDom.Providers.DotNetCompilerPlatform to 4.1.0 (latest) to get rid of old System.Http.Net dependency"

This reverts commit be2ba86.

* Reverting the addition of assembly binding redirects to Orchard.Specs/Hosting/Simple.Web/Web.config

since it doesn't need them like Orchard.Specs/Hosting/Orchard.Web/Web.config does

* Disabling Test and Spec execution for now

* Orchard.Framework: Making the System.Net.Http not-private to prevent an outdated version sticking around

* Orchard.Workflows: Adding assembly binding redirect for System.Net.Http to avoid Razor compilation warning

* Moving the System.Net.Http assembly redirect to Orchard.Web

* Specs: Fixing "I can create browse blog posts on several pages" Blog test's usage of "I should not see" and correcting the parameters too

because unlike "I should see", this is not a regex match, just contains

* Specs: Fixing "I can create browse blog posts on several pages" Blog test's flakyness due to timing

because the blog posts are created quickly after one another and the lack of millisecond-precision can cause
the blog posts to appear out of order of creation

* Specs: Media test simplified since the Orchard.Media feature is deprecated

* Adding step to the Compile workflow to upload the MSBuild binlog results

* Pinning the referenced version of System.Net.Http to 4.2.0.0 to prevent Razor compilation warning

System.Net.Http is known to have such problems across different framework versions ways of referencing it

The original warning is:
ASPNETCOMPILER : error : The following assembly has dependencies on a version of the .NET Framework that is higher than the target and might not load correctly during runtime causing a failure: Orchard.Workflows, Version=1.10.3.0, Culture=neutral, PublicKeyToken=null. The dependencies are: System.Net.Http, Version=4.2.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a. You should either ensure that the dependent assembly is correct for the target framework, or ensure that the target framework you are addressing is that of the dependent assembly. [D:\a\Orchard\Orchard\src\Orchard.Web\Modules\Orchard.Workflows\Orchard.Workflows.csproj

* Re-enabling the Test step

* Re-enabling the Specs step

* Marking System.Net.Http references as private (copy local) to make sure that it's always available, because it requires a specific version

* Revert "Marking System.Net.Http references as private (copy local) to make sure that it's always available, because it requires a specific version"

This reverts commit e4f5632.

* Orchard.Specs: Adding Settings feature

* Orchard.Specs: Updating DateTime.CreatingAndUsingDateTimeFieldsInAnotherCulture structure without functional change

* Orchard.Specs: Updating Settings.AddingANewSiteCultureAndSelectingItAsTheDefaultWorks to correctly detect that a culture that wasn't added before can be set as default

* Fixing Newtonsoft.Json references

* Specs: Workaround for the DefineDefaultCulture binding and removing the Settings feature which is now redundant with CreatingAndUsingDateTimeFieldsInAnotherCulture

* Updating the compile workflow to run the build + tests on PR, dev and 1.10.x commits

* Adding the compile workflow to the solution
BenedekFarkas added a commit to OrchardCMS/Orchard that referenced this issue Mar 8, 2024
* Fixing that RecipeManagerTests failed due to HttpContext not being available

* Fixing OwnerEditor tests in CommonPartProviderTests as the owner editor now checks for a different permission since 5b0c82d

* Fixing typo in CommonPartProviderTests.UpdateModelStub class name

* Fixing that test cases for invalid path in FileSystemStorageProviderTests broke in a3e9bef (issue #6802, PR #6919)

I should review PRs more carefully!

* Fixing CurrentCultureWorkContextTests

* Fixing indentation in DefaultDateFormatterTests

* Updating Orchard.Azure.Web's required version of System.Web.Mvc to match the rest of the solution

* Orchard.Specs: Fixing assembly loading errors when starting up the web host by adding binding redirects

* Adding empty compile workflow from dev

* Adding the compile workflow's actual contents

* Changing default shell to pwsh (msbuild was not found in cmd?)

* Adding msbuild to PATH

* Removing unused references to System.Net.Http

* Replacing System.Net.Http references with its NuGet package to pin the correct version number (experimental)

* Upgrading Microsoft.CodeDom.Providers.DotNetCompilerPlatform to 4.1.0 (latest) to get rid of old System.Http.Net dependency

* Orchard.proj: Spec target actually depends on only the Compile target, not Package-Stage (experimental)

* Compile workflow: Testing the Test and Spec targets

* Fixing Test step

* Fixing compile workflow to also mark Razor compilation warnings as errors

* Restoring Orchard.Specs/Hosting/Orchard.Web/Web.config to match Orchard.Web's web.config closer

so that it loads assemblies from the Dependencies folder.
This fixes the error with Autofac not being able to resolve dependencies for DefaultOrchardShell

* Orchard.Specs/Hosting/Orchard.Web/Global.asax.cs: Workaround for AntiForgeryToken bug in ASP.NET MVC since version 5.2.4

aspnet/AspNetWebStack#162

* Revert "Replacing System.Net.Http references with its NuGet package to pin the correct version number (experimental)"

This reverts commit 087f284.

* Revert "Upgrading Microsoft.CodeDom.Providers.DotNetCompilerPlatform to 4.1.0 (latest) to get rid of old System.Http.Net dependency"

This reverts commit be2ba86.

* Reverting the addition of assembly binding redirects to Orchard.Specs/Hosting/Simple.Web/Web.config

since it doesn't need them like Orchard.Specs/Hosting/Orchard.Web/Web.config does

* Disabling Test and Spec execution for now

* Orchard.Framework: Making the System.Net.Http not-private to prevent an outdated version sticking around

* Orchard.Workflows: Adding assembly binding redirect for System.Net.Http to avoid Razor compilation warning

* Moving the System.Net.Http assembly redirect to Orchard.Web

* Specs: Fixing "I can create browse blog posts on several pages" Blog test's usage of "I should not see" and correcting the parameters too

because unlike "I should see", this is not a regex match, just contains

* Specs: Fixing "I can create browse blog posts on several pages" Blog test's flakyness due to timing

because the blog posts are created quickly after one another and the lack of millisecond-precision can cause
the blog posts to appear out of order of creation

* Specs: Media test simplified since the Orchard.Media feature is deprecated

* Adding step to the Compile workflow to upload the MSBuild binlog results

* Pinning the referenced version of System.Net.Http to 4.2.0.0 to prevent Razor compilation warning

System.Net.Http is known to have such problems across different framework versions ways of referencing it

The original warning is:
ASPNETCOMPILER : error : The following assembly has dependencies on a version of the .NET Framework that is higher than the target and might not load correctly during runtime causing a failure: Orchard.Workflows, Version=1.10.3.0, Culture=neutral, PublicKeyToken=null. The dependencies are: System.Net.Http, Version=4.2.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a. You should either ensure that the dependent assembly is correct for the target framework, or ensure that the target framework you are addressing is that of the dependent assembly. [D:\a\Orchard\Orchard\src\Orchard.Web\Modules\Orchard.Workflows\Orchard.Workflows.csproj

* Re-enabling the Test step

* Re-enabling the Specs step

* Marking System.Net.Http references as private (copy local) to make sure that it's always available, because it requires a specific version

* Revert "Marking System.Net.Http references as private (copy local) to make sure that it's always available, because it requires a specific version"

This reverts commit e4f5632.

* Orchard.Specs: Adding Settings feature

* Orchard.Specs: Updating DateTime.CreatingAndUsingDateTimeFieldsInAnotherCulture structure without functional change

* Orchard.Specs: Updating Settings.AddingANewSiteCultureAndSelectingItAsTheDefaultWorks to correctly detect that a culture that wasn't added before can be set as default

* Fixing outdated assembly binding redirects

* Fixing Newtonsoft.Json references

* Updating Newtonsoft.Json reference in Orchard.Messaging.Tests.csproj

* Disabling the Test step for now

* Adding System.Net.Http 4.2.0.0 reference to Orchard.Email's web.config to fix Razor compilation warning

* Re-enabling the Test step

* Fixing HqlExpressionTests.AllDataTypesCanBeQueried

* Fixing initialization error error in StylesheetBindingStrategyTests

* Fixing initialization errors in FeatureManagerTests

* Fixing Orchard.Tests.Localization.TextTests

* Code styling and fixing warning in Orchard.Tests/UI/Resources/ResourceManagerTests.cs

* Updating Orchard.Tests/UI/Resources/ResourceManagerTests.cs according to ResourceManager API change in ac11024

and removing obsolete tests

* Orchard.Tests.Modules: Adding missing reference to Iesi.Collections (that doesn't cause a build error, just when running tests)

* Fixing initialization errors in ModuleStepTest and ThemeStepTest

* Fixing initialization errors in ShellDescriptorManagerTests

* Fixing initialization errors in AccountControllerTests

* Fixing that MembershipServiceTests should use IPasswordService, also making SaltAndPasswordShouldBeDifferentEvenWithSameSourcePassword test parameters more readable

* Specs: Updating the Newtonsoft.Json binding redirect in the spec app's web.config

* Re-enabling the Spec step

* Upgrading actions to latest versions

These actions generated the Node.js 16  deprecation warning

* Removing SpecFlow test execution from the compile workflow

* Testing the branch strategy matrix concept to be used for the nightly build

* Revert "Testing the branch strategy matrix concept to be used for the nightly build"

This reverts commit 1354e36.

* Adding workflow to run specflow tests as a nightly build

* Updating Orchard.Tests.ContentManagement.HqlExpressionTests.ShouldSortRandomly to decrease failure chance due to randomness
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants
@icnocop @dougbu @mkArtakMSFT @ParanoidPenguin and others