IIS下URL Rewrite与FormsAuthentication执行顺序冲突及跨应用池解决方案

环境背景 #

• 1个主站点，下设3个虚拟目录，对应3个独立应用池的ASP.NET MVC应用
• 所有应用均使用Forms Authentication
• 需求：通过URL Rewrite捕获错误URL，重写或跳转到对应应用

核心问题 #

• 跨应用池重写失效：使用URL重写时，因应用池隔离机制，无法正常提供服务（IIS已知跨应用池重写限制）
• 跳转优先级冲突：使用URL跳转时，Forms Authentication的登录跳转优先级更高。例如：已登录app1，但访问属于app1的app2路径时，app2因无会话触发登录跳转，而非执行预设的URL Rewrite跳转

尝试的无效方案 #

调整applicationHost.config（路径：C:\Windows\System32\inetsrv\Config）中的模块顺序，将RewriteModule置于FormsAuthentication模块之前，但未生效。相关配置片段：

<modules>
    <add name="IsapiModule" lockItem="true" />
    <add name="IsapiFilterModule" lockItem="true" />
    <add name="HttpLoggingModule" lockItem="true" />
    <add name="HttpCacheModule" lockItem="true" />
    <add name="StaticCompressionModule" lockItem="true" />
    <add name="DefaultDocumentModule" lockItem="true" />
    <add name="DirectoryListingModule" lockItem="true" />
    <add name="ProtocolSupportModule" lockItem="true" />
    <add name="HttpRedirectionModule" lockItem="true" />
    <add name="StaticFileModule" lockItem="true" />
    <add name="AnonymousAuthenticationModule" lockItem="true" />
    <add name="WindowsAuthenticationModule" lockItem="true" />
    <add name="RequestFilteringModule" lockItem="true" />
    <add name="CustomErrorModule" lockItem="true" />
    <add name="FailedRequestsTracingModule" lockItem="true" />
    <add name="ConfigurationValidationModule" lockItem="true" />
    <add name="OutputCache" type="System.Web.Caching.OutputCacheModule" preCondition="managedHandler" />
    <add name="RewriteModule" />
    <add name="Session" type="System.Web.SessionState.SessionStateModule" preCondition="managedHandler" />
    <add name="WindowsAuthentication" type="System.Web.Security.WindowsAuthenticationModule" preCondition="managedHandler" />
    <add name="FormsAuthentication" type="System.Web.Security.FormsAuthenticationModule" preCondition="managedHandler" />
    <add name="DefaultAuthentication" type="System.Web.Security.DefaultAuthenticationModule" preCondition="managedHandler" />
    <add name="RoleManager" type="System.Web.Security.RoleManagerModule" preCondition="managedHandler" />
    <add name="UrlAuthorization" type="System.Web.Security.UrlAuthorizationModule" preCondition="managedHandler" />
    <add name="FileAuthorization" type="System.Web.Security.FileAuthorizationModule" preCondition="managedHandler" />
    <add name="AnonymousIdentification" type="System.Web.Security.AnonymousIdentificationModule" preCondition="managedHandler" />
    <add name="Profile" type="System.Web.Profile.ProfileModule" preCondition="managedHandler" />
    <add name="UrlMappingsModule" type="System.Web.UrlMappingsModule" preCondition="managedHandler" />
    <add name="UrlRoutingModule-4.0" type="System.Web.Routing.UrlRoutingModule" preCondition="managedHandler,runtimeVersionv4.0" />
    <add name="ScriptModule-4.0" type="System.Web.Handlers.ScriptModule, System.Web.Extensions, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" preCondition="managedHandler,runtimeVersionv4.0" />
    <add name="ApplicationRequestRouting" />
</modules>
</system.webServer>

最终解决方案：ARR代理架构 #

将原有结构调整为4个独立站点：

• 1个ARR代理站点：仅配置URL Rewrite规则，启用ARR代理功能，解决跨应用池重写的隔离问题
• 3个原业务应用站点：保持独立应用池和Forms Authentication配置

关键实现细节 #

• 用版本记录文件存储当前最新应用版本号
• 通过自定义Cookie标记已登录用户的当前应用版本
• 开发自定义URL Rewrite Provider，实现逻辑：
  • 未登录用户：重写请求到最新版本的应用站点
  • 已登录用户：根据Cookie标记的版本，重写请求到对应版本的应用站点
• 优势：规避会话对象序列化问题，不影响已登录用户的站点启动性能

内容的提问来源于stack exchange，提问作者Domagoj