【问题标题】:Using IIS 7.5 warm-up module with ASP.NET MVC AuthorizeAttribute将 IIS 7.5 预热模块与 ASP.NET MVC AuthorizeAttribute 结合使用
【发布时间】:2011-02-21 20:32:42
【问题描述】:

我在我的 ASP.NET MVC 应用程序中创建了一个控制器来处理应用程序的预热/初始化(即初始加载 Web 服务客户端代理和其他最初可能需要大量时间的操作)。为了调用 WarmUp 控制器,我使用 IIS 7/7.5 预热模块在应用程序池启动时发送请求。

我不希望所有用户都能够执行 WarmUp 控制器操作,所以我用 [Authorize] 属性装饰了控制器。我什至在我的域中创建了一个组,其中包含应该被允许执行预热操作的用户,并将该组添加为授权属性的角色(即[Authorize(Roles = @"MyDomain\AppWarmUp")])。

如果我使用 Web 浏览器手动调用 WarmUp 控制器并提供正确的凭据,那么一切都会按预期工作。但是,在使用 IIS 预热模块时,即使我提供了正确的凭据,我也会在我的应用程序事件日志中看到警告,指出身份验证失败。

如果我只为预热模块的用户上下文指定类型和用户名,我会收到带有消息的ProviderException

仅当用户名参数与当前 Windows 标识中的用户名匹配时才支持该方法。

如果我同时指定用户名和密码/令牌,我会收到带有以下消息的 ArgumentException

用于模拟的令牌无效 - 不能复制。

如果我从我的控制器中删除[Authorize] 属性,那么预热模块的请求将毫无例外地通过。但是,如果可能的话,我想避免所有用户都可以访问 WarmUp 控制器的情况。这可能是热身模块中的错误还是我遗漏了什么?

可能还值得注意的是,我也尝试了 ASP.NET 4.0 应用程序自动启动功能,但它似乎与向应用程序发出实际请求的效果不同。还有其他选择吗?

【问题讨论】:

    标签: asp.net-mvc iis asp.net-mvc-3 iis-7.5


    【解决方案1】:

    问题可能是由于用户帐户在 IIS 中用于在您的站点中执行预热请求。确保更改应用程序池高级设置下的身份设置以及网站高级设置下的物理路径凭据。我不记得其中哪一个会起作用,所以尝试一个/或/两个。

    当您从浏览器手动发出请求时,您就是在模拟帐户。当 IIS 通过 WarmUp 模块发出请求时,它使用的是上面指定的帐户之一。

    【讨论】:

      猜你喜欢
      • 2011-11-15
      • 2014-06-03
      • 1970-01-01
      • 2011-01-23
      • 1970-01-01
      • 2011-01-09
      • 1970-01-01
      • 2015-11-26
      相关资源
      最近更新 更多