nTier应用程序中的.Net会员资格

前端之家收集整理的这篇文章主要介绍了nTier应用程序中的.Net会员资格前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。
说我有一个ASP.Net MVC应用程序,这个应用程序(UI)引用一个业务逻辑层(BLL),BLL引用我的数据访问层(DAL).

我正在使用自定义会员和角色提供商进行授权.

我正在尝试确定哪些层需要引用我的会员提供商.

在MVC中,您可以通过以下方式执行授权检查:

[Authorize(Roles = "SomeRoleName")]
public ActionResult Index()
{
//do something
}

在我的BLL中,我可能想查看一个用户是否也在一个角色:

public static bool IsRoleEditor(User user,Role userRole)
  {
   bool retValue = false;

   if (user.Application.AppID == UserRole.Application.AppID)
   {
        if (Roles.IsUserInRole("ModifyRoles"))
        {
           retValue = true;
        }


    return retValue;
   }

如果我这样做,我将不得不引用并实例化两层的Membership类.这是建筑这样的应用程序的正确方法吗?似乎很多冗余.

因为我有一个BLL,我不要使用“[Authorize(Roles =”SomeRoleName“)]”属性,而是从MVC代码调用一个BLL函数来检查用户是否在一个角色?如果我这样做,MVC仍然需要参考会员提供商进行身份验证,无论如何,要利用登录和其他ASP控件,对吧?

我是否离开基地,走向错误的方向?

解决方法

在我看来,这是会员/角色设计的弱点.

我将围绕这一点,例如在分布式n层应用程序中对UI和BLL层进行基于角色的授权,将会暴露BLL层中暴露相关位(GetRolesForUser等)和通过在服务器上调用RoleProvider实现.

然后通过调用BLL公开的服务来实现客户端上的一个自定义RoleProvider.

以这种方式,UI层和BLL层都共享相同的RoleProvider. UI层可以使用当前用户角色的知识来改进UI(例如隐藏/禁用与未授权的功能相对应的UI控件),并且BLL可以确保用户不能执行他们没有授权的业务逻辑.

猜你在找的asp.Net相关文章