Winforms 基于角色的安全限制

发布于 2024-08-28 01:59:10 字数 401 浏览 7 评论 0原文

我正在使用 Microsoft 的成员资格和角色提供程序来实现基于角色的安全性。

我遇到的理论问题是,您在方法上实现特定角色,例如:

[PrincipalPermissionAttribute(SecurityAction.Demand, Role="Supervisor")]
private void someMethod() {}

如果在未来的某个时刻,我希望主管再访问 someMethod() 怎么办?

我是否必须更改源代码才能进行更改?我错过了什么吗?

似乎必须有某种方法来抽象主管角色和方法之间的关系,以便我可以在应用程序中创建一种方法来更改角色权限与方法之间的这种耦合。

任何见解或方向将不胜感激。谢谢。

I'm implementing role based security using Microsoft's membership and role provider.

The theoretical problem I'm having is that you implement a specific role on a method such as:

[PrincipalPermissionAttribute(SecurityAction.Demand, Role="Supervisor")]
private void someMethod() {}

What if at some point down the road, I don't want Supervisors to access someMethod() anymore?

Wouldn't I have to change the source code to make that change? Am I missing something?

It seems there has to be some way to abstract the relationship between the supervisors role and the method so I can create a way in the application to change this coupling of role permission to method.

Any insight or direction would be appreciated. Thank you.

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

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

发布评论

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

评论(2

陪我终i 2024-09-04 01:59:10

如果您使用声明性方法,那么是的 - 如果您突然不希望 Supervisor 的成员能够调用您的方法,您需要为此更改源代码。

但是,您也可以在代码中以编程方式完成所有这些操作:

private void someMethod() 
{
    WindowsPrincipal currentUser = (Thread.CurrentPrincipal as WindowsPrincipal);
    if (currentUser != null)
    {
        if (currentUser.IsInRole("Supervisor"))
        {
            // do something here
        }
    }

}

您始终可以获取 Winforms 应用程序正在运行的当前 Windows 主体,然后您可以调用 IsInRole 方法来检查是否给定的用户具有给定的角色。当然,您也可以将所有这些配置为可配置,例如从配置文件中读取所需的角色,如果您想允许所有人进入,您只需将角色更改为Users或其他

If you use the declarative approach, then yes - if you suddenly don't want members of the Supervisor to be able to call your method, you need to change your source code for that.

You can, however, also do all of this in code, programmatically:

private void someMethod() 
{
    WindowsPrincipal currentUser = (Thread.CurrentPrincipal as WindowsPrincipal);
    if (currentUser != null)
    {
        if (currentUser.IsInRole("Supervisor"))
        {
            // do something here
        }
    }

}

You can always get the current Windows principal your Winforms app is running under, and then you can call the IsInRole method to check whether or not a given user is in a given role. Of course, you can also make all of this configurable, e.g. read the required role from a config file, and if you want to allow everyone in, you just simply change the role to be Users or something

小梨窩很甜 2024-09-04 01:59:10

由于您提到的原因,PrincipalPermissionAttribute 并不倾向于在我开发的许多应用程序中使用;该属性应用只能通过代码更改来更改的策略。

另一种方法是直接使用 PrincipalPermission 类。所有安全属性在运行时解析为类似命名的类和方法调用。对于您的属性,将执行以下代码:

PrincipalPermission permission = new PrincipalPermission(null, "Supervisor");
permission.Demand(); // Throws SecurityException if user is not in the role.

如果直接使用权限类,您可以更好地控制权限的形成方式。您可以拥有一个数据库,您可以查询该数据库来获取角色列表并执行对它们的需求,如下所示:

private void someMethod()
{
    IEnumerable<string> roles = GetRolesForMethod("someMethod");

    PrincipalPermission permission = null;

    foreach(string role in roles)
    {
        if(permission == null)
        {
            permission = new PrincipalPermission(null, role);
        }
        else
        {
            permission = permission.Union(
                new PrincipalPermission(null, role);
                );
        }
    }

    if(permission != null)
    {
        permission.Demand();
    }
}

PrincipalPermissionAttribute does not tend to be used in many applications I've worked on for the reason you've touched upon; the attribute applies a policy which can only be altered by a code change.

The alternative is to use the PrincipalPermission class directly. All security attributes resolve to similarly named classes and method calls at run time. In the case of your attribute, the following code is executed:

PrincipalPermission permission = new PrincipalPermission(null, "Supervisor");
permission.Demand(); // Throws SecurityException if user is not in the role.

If you use the permission classes directly, you gain more control over how your permissions are formed. You could have a database which you query to get a list of roles and perform a demand for them like this:

private void someMethod()
{
    IEnumerable<string> roles = GetRolesForMethod("someMethod");

    PrincipalPermission permission = null;

    foreach(string role in roles)
    {
        if(permission == null)
        {
            permission = new PrincipalPermission(null, role);
        }
        else
        {
            permission = permission.Union(
                new PrincipalPermission(null, role);
                );
        }
    }

    if(permission != null)
    {
        permission.Demand();
    }
}
~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文