IIS - 集成管道模式下默认文档的不同处理?

发布于 2024-07-14 15:42:32 字数 948 浏览 4 评论 0原文

我有一个 HTTP 模块来处理来自 Facebook 的身份验证,它在经典管道模式下运行良好。

然而,在集成管道模式下,我看到默认文档传递了一个额外的请求,这导致模块失败。 我们查看(来自 Facebook 的)请求,以检索并验证访问我们应用程序的用户。 初始请求身份验证正常,但随后我看到第二个请求,该请求缺少发布的表单变量,从而导致身份验证失败。

在集成管道模式下,对“/”的 http 请求会连续产生 2 个 AuthenticateRequest:

  1. AppRelativeCurrentExecutionFilePath = "~/" 的请求
  2. AppRelativeCurrentExecutionFilePath = "~/default.aspx" 的请求

第二个请求会丢失所有表单值,所以它无法验证。 在经典模式下,第二个请求是唯一发生的请求,并且它保留表单值。

有什么想法吗?

更新:这是 IIS 中模块通知的跟踪图像。 请注意,我的模块 FBAuth 多次看到 AUTHENTICATE_REQUEST (我期望 2 次 - 一次用于身份验证,一次用于后验证,但我得到了 4 次)。

事件多次引发

我开始相信这与模块/过滤器配置,因为我发现一个运行相同代码的(Vista)框不会重复触发这些事件 - 它的行为符合预期。 我正在努力找出其中的区别...

谢谢! 汤姆

I have an HTTP Module to handle authentication from Facebook, which works fine in classic pipeline mode.

In integrated pipeline mode, however, I'm seeing an additional request pass through for the default document, which is causing the module to fail. We look at the request (from Facebook) to retrieve and validate the user accessing our app. The initial request authenticates fine, but then I see a second request, which lacks the posted form variables, and thus causes authentication to fail.

In integrated pipeline mode, an http request for "/" yields 2 AuthenticateRequests in a row:

  1. A request where AppRelativeCurrentExecutionFilePath = "~/"
  2. A request where AppRelativeCurrentExecutionFilePath = "~/default.aspx"

That second request loses all of the form values, so it fails to authenticate. In classic mode, that second request is the only one that happens, and it preserves the form values.

Any ideas what's going on here?

UPDATE: Here is an image of the trace from module notifications in IIS. Note that my module, FBAuth, is seeing AUTHENTICATE_REQUEST multiple times (I'd expect 2 - one for authenticate and one for postauthenticate, but I get 4).

Events raised multiple times

I'm starting to believe this has something to do with module/filter configuration because I've found a (Vista) box running the same code that doesn't fire these events repeatedly - it behaves as expected. I'm working through trying to figure out what the difference could be...

Thanks!
Tom

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

我三岁 2024-07-21 15:42:33

我的解决方案是在Application_BeginRequest末尾添加以下代码:

if (Request.RawUrl.TrimEnd('/') == HostingEnvironment.ApplicationVirtualPath.TrimEnd('/'))
    Server.Transfer(Request.RawUrl+"Default.aspx", true);

My solution was to add the following code at the end of Application_BeginRequest:

if (Request.RawUrl.TrimEnd('/') == HostingEnvironment.ApplicationVirtualPath.TrimEnd('/'))
    Server.Transfer(Request.RawUrl+"Default.aspx", true);
绮烟 2024-07-21 15:42:33

不支持DefaultHttpHandler,
所以依赖子类的应用程序
DefaultHttpHandler 将无法
服务请求如果您的应用程序
使用 DefaultHttpHandler 或处理程序
派生自 DefaultHttpHandler,
它将无法正常工作。 在
集成模式,处理程序派生自
DefaultHttpHandler 将无法
将请求传回 IIS
处理,而不是服务于
请求的资源作为静态文件。
集成模式允许 ASP.NET 模块
运行所有请求,无需
需要使用
DefaultHttpHandler。

解决方法

更改您的应用程序以使用
执行请求处理的模块
对于所有请求,而不是使用
通配符映射将 ASP.NET 映射到所有
请求,然后使用
DefaultHttpHandler 派生处理程序
将请求传递回 IIS。

嗯,或者这可能就是问题所在。

早期请求中的 ASP.NET 模块
处理阶段将看到请求
之前可能被拒绝的
在进入 ASP.NET 之前通过 IIS,
其中包括运行在的模块
BeginRequest 看到匿名请求
对于需要的资源
身份验证 ASP.NET 模块可以运行
在任何管道阶段
可用于本机 IIS 模块。
正因为如此,要求
之前可能已被拒绝
身份验证阶段(例如
匿名请求资源
需要身份验证)或其他
进入 ASP.NET 之前的阶段可能
运行 ASP.NET 模块。 这种行为是
设计目的是为了启用 ASP.NET
在所有请求中扩展 IIS 的模块
处理阶段。

解决方法

更改应用程序代码以避免
任何特定于应用程序的问题
源于看到可能的请求
稍后在请求期间被拒绝
加工。 这可能涉及改变
订阅管道的模块
稍后引发的事件
请求处理。
http://learn.iis .net/page.aspx/381/aspnet-20-writing-changes-on-iis-70/

DefaultHttpHandler is not supported,
so applications relying on sub-classes
of DefaultHttpHandler will not be able
to serve requests If your application
uses DefaultHttpHandler or handlers
that derive from DefaultHttpHandler,
it will not function correctly. In
Integrated mode, handlers derived from
DefaultHttpHandler will not be able to
pass the request back to IIS for
processing, and instead serve the
requested resource as a static file.
Integrated mode allows ASP.NET modules
to run for all requests without
requiring the use of
DefaultHttpHandler.

Workaround

Change your application to use
modules to perform request processing
for all requests, instead of using
wildcard mapping to map ASP.NET to all
requests and then using
DefaultHttpHandler derived handlers to
pass the request back to IIS.

Hmmm, or this could be the issue.

ASP.NET modules in early request
processing stages will see requests
that previously may have been rejected
by IIS prior to entering ASP.NET,
which includes modules running in
BeginRequest seeing anonymous requests
for resources that require
authentication ASP.NET modules can run
in any pipeline stages that are
available to native IIS modules.
Because of this, requests that
previously may have been rejected in
the authentication stage (such as
anonymous requests for resources that
require authentication) or other
stages prior to entering ASP.NET may
run ASP.NET modules. This behavior is
by design in order to enable ASP.NET
modules to extend IIS in all request
processing stages.

Workaround

Change application code to avoid
any application-specific problems that
arise from seeing requests that may be
rejected later on during request
processing. This may involve changing
modules to subscribe to pipeline
events that are raised later during
request processing.
http://learn.iis.net/page.aspx/381/aspnet-20-breaking-changes-on-iis-70/

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文