ASP.Net MVC 会员资格

发布于 2024-08-13 12:06:47 字数 452 浏览 9 评论 0原文

我想使用 AuthorizeAttribute 来控制允许哪些用户访问我的操作。我只是想澄清一下我的逻辑是正确的。

  1. 我创建了自己的 IPrincipal 实现,
  2. 并将用户的凭据发布到安全控制器的登录操作。
  3. 我使用 UserService 类验证凭据,并将从 UserService 类返回的 IPrincipal 分配给 HttpContext.User
  4. 我的 WebAuthorizeAttribute(它继承 AuthorizeAttribute)检查当前的 HttpContext.User.Identity.IsAuthenticated 和 HttpContext.User.IsInRole 以确定用户是否具有访问该操作。

事情的发展是正常的吗?我知道我可以继承 MembershipProvider,但我不需要那里的所有功能,实际上只是使用两个不同角色登录的能力。

I want to use the the AuthorizeAttribute to control which users are allowed access to my actions. I just want to clarify that my logic is in order.

  1. I create my own implementation of IPrincipal
  2. I post a user's credentials to a login action of a security controller.
  3. I validate the credentials with a UserService class and assign the IPrincipal returned from my UserService class to HttpContext.User
  4. My WebAuthorizeAttribute, which inherits AuthorizeAttribute, checks the current HttpContext.User.Identity.IsAuthenticated and HttpContext.User.IsInRole to determine if the user has access to the action.

Is the the normal flow of things? I know I could inherit MembershipProvider, but I don't need all of the functionality there, really just the ability to login with two different roles.

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

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

发布评论

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

评论(2

咽泪装欢 2024-08-20 12:06:47

您必须将 IPrincipal 存储在某处,并在每次请求时恢复它。如果您将使用 FormsAuthentication,这是一个很好的解决方案:

ASP.NET 2.0 Forms 身份验证 - 保持自定义但简单

您可以在此处找到其他解决方案:

使用表单身份验证在 ASP.NET MVC 上的何处存储记录的用户信息?

并且可能在许多其他 StackOverflow 问题中:)

编辑

关于 MyBusinessLayerSecurityClass.CreatePrincipal(id, id.Name):

您应该阅读此页面:

http://msdn.microsoft.com/en-us/library/aa480476.aspx

特别是这个:


表单身份验证模块
类构造一个
通用主体
对象并将其存储在 HTTP 中
语境。这
通用主体
对象持有对a的引用
表单身份
代表当前的实例
经过身份验证的用户。你应该允许
表单身份验证来管理这些
给你的任务。如果您的应用程序
有特定要求,例如
设置用户
属性到自定义类
实施
IPrincipal接口,
你的应用程序应该处理
后验证
事件。这
后验证
事件发生后
表单身份验证模块
已验证表单身份验证
cookie 并创建了
GenericPrincipal
表单身份
对象。在此代码中,您可以
构造一个自定义的
IPrincipal 对象
包裹着
FormsIdentity 对象,
然后将其存储在
HttpContext。 用户
属性。

设置身份验证 cookie 后,FormsIdentity 会自动管理。您所要做的就是将其包装在您的 IPrincipal 中。当 HttpContext.Current.User 属性不为 null(它是 GenericPrincipal,不久后您将替换它)时,所有这些都会发生。当 HttpContext.Current.User 为 null 时,则之前没有创建身份验证 cookie,并且用户未经过身份验证。

You'll have to store IPrincipal somewhere and restore it with every request. If you'll use FormsAuthentication, this is good solution:

ASP.NET 2.0 Forms authentication - Keeping it customized yet simple

you can find other solutions here:

Where to store logged user information on ASP.NET MVC using Forms Authentication?

and propably in many other StackOverflow questions:)

EDIT

About MyBusinessLayerSecurityClass.CreatePrincipal(id, id.Name):

You should read this page:

http://msdn.microsoft.com/en-us/library/aa480476.aspx

Specially this:

The
FormsAuthenticationModule
class constructs a
GenericPrincipal
object and stores it in the HTTP
context. The
GenericPrincipal
object holds a reference to a
FormsIdentity
instance that represents the currently
authenticated user. You should allow
forms authentication to manage these
tasks for you. If your applications
have specific requirements, such as
setting the User
property to a custom class that
implements the
IPrincipal interface,
your application should handle the
PostAuthenticate
event. The
PostAuthenticate
event occurs after the
FormsAuthenticationModule
has verified the forms authentication
cookie and created the
GenericPrincipal and
FormsIdentity
objects. Within this code, you can
construct a custom
IPrincipal object
that wraps the
FormsIdentity object,
and then store it in the
HttpContext. User
property.

FormsIdentity is managed automatically after you set authentication cookie. All you have to do is wrap it up in your IPrincipal. All this happens when HttpContext.Current.User property is not null (it is GenericPrincipal, which you replace shortly after). When HttpContext.Current.User is null then there was no authentication cookie created earlier and user is not authenticated.

很酷又爱笑 2024-08-20 12:06:47

我认为以下情况更为典型:

  1. 我创建自己的 IPrincipal 实现
  2. 我将用户的凭据发布到安全控制器的登录操作。
  3. 我使用 UserService 类验证凭据,并构造一个包含该用户的一些识别信息的 cookie。通常使用 FormsAuthentication.SetAuthCookie 或该类实用方法的某种组合。
  4. 在应用程序 AuthenticateRequest 事件中,检查 cookie 并分配 Context.User。 注意:在 AuthenticateRequest 事件发生后,该值会自动分配给 Thread.CurrentPrincipal。这是一次性分配,此后这些值不会自动同步。
  5. 我的 WebAuthorizeAttribute 继承了 AuthorizeAttribute,它检查当前的 HttpContext.User.Identity.IsAuthenticated 和 HttpContext.User.IsInRole 以确定用户是否有权访问该操作。

I believe the following is more typical:

  1. I create my own implementation of IPrincipal
  2. I post a user's credentials to a login action of a security controller.
  3. I validate the credentials with a UserService class and construct a cookie that has some identifying information for this user. Typically FormsAuthentication.SetAuthCookie or some combination of that class's utility methods are used.
  4. In the Application AuthenticateRequest event, inspect the cookie and assign Context.User. Note: This value is automatically assigned to Thread.CurrentPrincipal after the AuthenticateRequest event. This is a one-time assignment and these values are not automatically synchronized thereafter.
  5. My WebAuthorizeAttribute, which inherits AuthorizeAttribute, checks the current HttpContext.User.Identity.IsAuthenticated and HttpContext.User.IsInRole to determine if the user has access to the action.
~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文