我有一个 HTTP 模块来处理来自 Facebook 的身份验证,它在经典流水线模式下工作正常。
但是,在集成管道模式下,我看到默认文档的其他请求通过,这导致模块失败。我们查看请求(来自 Facebook)以检索和验证访问我们的应用程序的用户。初始请求验证正常,但后来我看到第二个请求,缺少已发布的表单变量,从而导致身份验证失败。
在集成管道模式中,“/”的 http 请求连续产生 2 个 AuthenticateRequests:
-
AppRelativeCurrentExecutionFilePath =“~/”的请求
-
AppRelativeCurrentExecutionFilePath =“~/default.aspx”的请求
第二个请求丢失了所有表单值,因此无法进行身份验证。在经典模式中,第二个请求是唯一发生的请求,它保留了表单值。
有什么想法在这里发生了什么?
更新:这是 IIS 中模块通知的跟踪图像。请注意,我的模块 FBAuth 多次看到 AUTHENTICATE_REQUEST(我希望 2 - 1 用于身份验证,1 用于 postauthenticate,但我得到 4)。
我开始相信这与 module/filter 配置有关,因为我发现一个(Vista)框运行相同的代码,不会反复触发这些事件 - 它的行为与预期一致。我正在努力弄清楚差异可能是什么......
谢谢!汤姆
2 回答
你找到了解决方案吗?我想在 Application_BeginRequest 末尾添加以下代码:
****解决方法
更改应用程序以使用模块对所有请求执行请求处理,而不是使用通配符映射将 ASP.NET 映射到所有请求,然后使用 DefaultHttpHandler 派生处理程序将请求传递回 IIS。
嗯,或者这可能是个问题。
早期请求处理阶段中的 ASP.NET 模块将看到以前在进入 ASP.NET 之前可能已被 IIS 拒绝的请求,其中包括在 BeginRequest 中运行的模块,其中查看对需要身份验证的资源的匿名请求 ASP.NET 模块可以在本机可用的任何管道阶段中运行 IIS 模块。因此,先前可能在身份验证阶段被拒绝的请求(例如对需要身份验证的资源的匿名请求)或在进入 ASP.NET 之前的其他阶段可能会运行 ASP.NET 模块。此行为是设计用于使 ASP.NET 模块在所有请求处理阶段中扩展 IIS。
****解决方法
更改应用程序代码以避免因查看请求处理期间可能在以后拒绝的请求而导致的任何 application-specific 问题。这可能涉及更改模块以订阅稍后在请求处理期间引发的管道事件。 http://learn.iis.net/page.aspx/381/aspnet-20-breaking-changes-on-iis-70/