【发布时间】:2012-07-13 18:33:42
【问题描述】:
我的 ASP.NET MVC4 Web 应用程序有一个自定义主体/身份。我还创建了一个 AuthorizeAttribute 来实例化我的自定义主体,将其分配给我需要身份验证的控制器中的 httpContext.User。
这对于使用我的 AuthorizeAttribute 修饰的控制器/操作非常有用,但是,对于不需要身份验证的控制器(但如果它存在的话仍然使用它),我想获得我的 CustomPrincipal (最好通过 HttpContext.User).
在这些未修饰的控制器/动作中,设置了 HttpContext.User,但使用的是 GenericPrincipal 而不是我的 CustomPrincipal。 将 HttpContext.User 的默认设置“覆盖”到 GenericPrincipal 的最佳位置在哪里?
同样,如果在每个具有身份验证 cookie 的请求中都执行此操作,在 AuthorizeAttribute 装饰控制器的情况下,我将如何避免做两次工作(然后它会变成一个强制认证)。
为了清楚起见,我的网站允许匿名用户访问,但在这些页面上,如果某个页面通过了身份验证(并且实现了 CustomPrincipal),则提供了额外的功能。
我认为有些选项是(不确定每个选项背后的逻辑):
- 使用会话(并处理逻辑来创建我需要的内容,忘记 Principals)
- Application_AuthenticateRequest - 在网络上看到 cmet 认为这是老派
- 在基本控制器上设置自定义过滤器
- 在基本控制器上创建一个 AuthorizationAttribute,让每个人都可以通过并根据需要设置 HttpContext.User
- IHttpModule - 这似乎是一种下降方式(除非其他人不同意,否则沿着这条路前进)。
想法?
【问题讨论】:
-
AuthenticateRequest有什么问题?您只是觉得有问题还是发现了技术问题?我问这个,因为我相信自定义模块上的 AuthenticateRequest 是正确的方法。 -
使用 application_authenticaterequest 或 ihttpmodule 挂钩到 authenticaterequest 本质上是等效的。只是模块可以在运行时换出,重用等比 global.asax 中的代码块更容易
标签: asp.net asp.net-mvc forms-authentication iprincipal