ASP.NET 2.0和4.0似乎在窗体身份验证区别对待的根URL [英] ASP.NET 2.0 and 4.0 seem to treat the root url differently in Forms Authentication

问题描述

如果有如下的的web.config ：

<configuration>
  <system.web>
    <authentication mode="Forms">
      <forms name="MembershipCookie" 
             loginUrl="Login.aspx" 
             protection="All" 
             timeout="525600" 
             slidingExpiration="true" 
             enableCrossAppRedirects="true" 
             path="/" />
    </authentication>
    <authorization>
      <deny users="?"  />
    </authorization>
  </system.web>
  <location path="Default.aspx">
    <system.web>
      <authorization>
        <allow users="*"/>
      </authorization>
    </system.web>
  </location>
</configuration>

该应用程序是在Windows 2008 R2 / IIS7.5运行ASP.NET 2.0应用程序。

The application is an ASP.NET 2.0 application running on Windows 2008R2/IIS7.5.

如果该网站的应用程序池配置为运行ASP.NET 2.0和我浏览 http://example.com 然后的Default.aspx 如你从上面的规则的期待呈现。

If the site's application pool is configured to run ASP.NET 2.0 and I browse to http://example.com then Default.aspx is rendered as you'd expect from the rules above.

但是，如果应用程序池设置为运行ASP.NET 4.0，我重定向至登录页面。如果我明确指定 http://example.com/default.aspx 那么一切都很好， Default.aspx的渲染

However if the application pool is set to run ASP.NET 4.0 I am redirected to the login page. If I explicitly specify http://example.com/default.aspx then all is good and default.aspx renders.

我试图重写 / - ＆GT; /default.aspx （使用IIS 2.0 UrlRewriter），但结果还是一样，我被踢出到登录页面。

I've tried rewriting / -> /default.aspx (using IIS UrlRewriter 2.0) but the result is still the same, I get kicked to the login page.

我也与ASP.NET 4.0应用程序具有相同的结果试过这种（这是哪里出了问题最初提出的）。我用2.0应用程序尝试这样做的原因是为了看看是否有行为上的变化，似乎 / 的是的在4.0的处理方式不同

I've also tried this with an ASP.NET 4.0 application with the same result (which is where the problem initially arose). The reason I tried this with a 2.0 application was to see if there was a change in behaviour, and it seems that / is handled differently in 4.0.

总结一下，使用上面的配置符合下列条件：

So to summarise, using the configuration above the following is observed:

ASP.NET Version  Url                                 Behaviour
-------------------------------------------------------------------------
2.0              http://example.com                  Renders Default.aspx
2.0              http://example.com/Default.aspx     Renders Default.aspx
4.0              http://example.com                  Redirects to Login.aspx
4.0              http://example.com/Default.aspx     Renders Default.aspx

这是一个bug /重大更改或有我错过了什么昭然若揭？

Is this a bug/breaking change or have I missed something glaringly obvious?

更新：

我有这个问题的底部，见下面我自己的答案。

I have got to the bottom of this issue, see my own answer below.

推荐答案

找到罪魁祸首。由于我们WebDeploy 2.0 / WebMatrix的服务器端部分的改变此修复程序是由的 WebMatrix的服务器验证：

Found the culprit. As part of our WebDeploy 2.0/WebMatrix server side changes this hotfix is recommended by the WebMatrix Server Validator:

MS KB：980368 - 一个有可用更新，使某些IIS 7.0或者IIS 7.5的处理程序来处理其请求网址不是以句点结束

安装此热修复程序会导致ASP.NET 4.0来更改请求只是一个网址的域名部分窗体身份验证的行为。

Installing this hot fix causes ASP.NET 4.0 to change the Forms Authentication behaviour where just the domain name part of a url is requested.

更新1：

这QFE也是2008R2的Windows SP1的一部分，也将打破ASP.NET 4.0中的窗体身份验证在上述方式。

This QFE is also part of Windows 2008R2 SP1 and will also break ASP.NET 4.0's Forms Authentication in the manner described above.

更新2：

此外，该运行在配置为ASP.NET和放大器运行一个应用程序池传统的ASP应用程序时，也打破默认文档处理;经典管道模式。

In addition this also breaks default document handling when running classic ASP applications in an application pool configured to run as ASP.NET & Classic Pipeline mode.

服务器返回一个 404.2 - 找不到错误

同样重大更改适用于Windows 2008 R2 SP1。

The same breaking change applies to Windows 2008R2 SP1.

更新3：

我报这MS PSS，他们证实了行为上的重大更改。他们创造了针对此知识库文章给我们（和presumably等）已经受到它的影响：

I reported this to MS PSS and they confirmed a breaking change in behaviour. They created this KB article in response to us (and presumably others) having been affected by it:

Web服务可能无法在Microsoft Internet信息服务（IIS）7.5和Windows 7 Service Pack 1的使用.NET框架4.0由于扩展名的URL处理程序

在我自己来说，我基本上删除（或建议客户），如果此问题影响的扩展名的处理程序：

In my own case I basically remove (or advise customers to) the extensionless handlers if impacted by this problem:

<configuration>
  <system.webServer>
    <handlers>
      <remove name="ExtensionlessUrl-Integrated-4.0" />
      <remove name="ExtensionlessUrl-ISAPI-4.0_64bit" />
      <remove name="ExtensionlessUrl-ISAPI-4.0_32bit" />
    </handlers>
  </system.webServer>
</configuration>

这篇关于ASP.NET 2.0和4.0似乎在窗体身份验证区别对待的根URL的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！