实体框架:权限、用户等的关系模型帮助

发布于 2024-11-29 12:04:19 字数 805 浏览 1 评论 0原文

有人可以帮忙吗?

我希望创建一个良好的关系模型来管理权限。

我目前有一个用户表和各种其他表,例如客户、供应商。

用户需要在客户、供应商中查看、编辑、创建的权限。

我将使用 EF 中的这些表来决定用户拥有哪些访问权限以及是否显示表单等。

我的原始模型是这样的,尽管我认为它是错误的,因为它没有说明任何有关权限的信息。

用户 UsersCustomers(包含用户和客户之间的关系) UsersSuppliers(包含用户和供应商之间的关系) 客户(客户表) 供应商(供应商表)。

虽然这可行,例如它将用户与客户联系起来......但它似乎不太正确。

我正在考虑放置一个名为 Permissions 的中间表,它有一个 Id 和一个连接用户表的 UserId。 之类的表

然后我可以将 Permissions 链接到PermissionsCustomers(代替 UsersCustomers)

,该表将包含权限和客户之间的关系。我认为这是我还没有得到最佳设计的地方。一旦这个设计正确,它也会缺少一个表来分配用户对客户拥有什么类型的权限,即编辑、创建或仅查看等。

我很想听到一些反馈或现有的强大模型的示例像这样的功能。

关于客户、供应商,这只是 2 个例子,还会有更多的表,例如deliveryLocation、accountsLedger 等。

目前,如果我可以执行一个查询“显示用户 X 拥有的所有权限”,那就太好了根据我的设置,我必须单独查询每个中间表。

我将通过类似 ORM 的实体框架来使用它。

对关系模型的结构有点迷失。

提前致谢。

Can anyone help?

I am looking to create a good relational model for managing Permissions.

I currently have a Users table, and various other tables like Customers, Suppliers.

The user needs permissions to View, Edit, Create in either Customers, Suppliers.

I will use these tables in EF to decide what access a user has and weather to show a form or not etc.

My original model goes like this, although i think its wrong, as it dosn't state anything about Permissions.

Users
UsersCustomers (contains relation between Users and Customers)
UsersSuppliers (contains relation between Users and Suppliers)
Customers (customer table)
Suppliers (suppliers table).

Although this works, i.e. it relates a user to a Customer for example... It just doesn't seem right.

I was thinking of putting a intermediate table called Permissions which woul have a Id and a UserId that would link the user table. Then i could link Permissions to a table like

PermissionsCustomers (in place of UsersCustomers) that would contain a relation between the persmission and customers.

I think this where i am not quite getting an optimum design. Once this design is correct it would be also missing a table to assign what type of permission a user has to a Customer i.e. Edit, Create or only view etc.

I would love to hear some feedback or an example of a strong model that exists that functions like this.

With regards to the customers, suppliers, these are just 2 examples, there will be lots more tables like deliveryLocation, accountsLedger etc.

It would be great if i could do a query that said "Show me all permissions that user X has", currently with my setup i would have to query each Intermediate table separately.

I would be using this via an ORM like entity framework.

A little lost with the structure of the relational model.

Thanks in advance.

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

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

发布评论

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

评论(1

等风也等你 2024-12-06 12:04:19

鉴于您的客户和供应商数量非常少(总共 20 个),因此您不需要非常复杂的系统。

我在类似情况下所做的就是设置一个权限表,其结构如下:

  • UserId(用户 ID)
  • RoleId(链接到角色表的 ID,其中包含“编辑客户”、删除供应商“、查看客户”
    等)
  • ObjectId(这将是标识任何内容的 id)
    然后

角色表将具有:

  • Id(与权限表中的 RoleId 相关的唯一 ID)
  • 名称(角色的唯一名称,即“编辑客户”)

每个用户实体链接到一个权限表,每个用户拥有多个权限。当用户登录时,我通常会选择将其所有权限加载到内存列表中,因此用户将拥有一个权限列表。权限列表将只有 ObjectId、RoleName 和/或 RoleId(我倾向于使用角色名来使代码更易于阅读,如下面的示例所示)

protected bool HasPermission(long ObjectId, string RoleName)
{

//Users in the Administrator role have access to everything in the system.
if (this.IsAdministrator) {
    HasPermission = true;
    return;
}

foreach (Permission P in Permissions) {
    if (P.ObjectID == ObjectID & P.RoleName == Role) {
        HasPermission = true;
        return;
    }
}
return false;

}

,然后,如果我想知道用户是否具有权限我会这样做:

if (myUser.HasPermission(CustomerId, "Edit Customer") {
  //allow the user to edit the customer
else
  //allow the user to only view the customer (for example)

或者

    if (myUser.HasPermission(SupplierId, "Print Supplier") {
  //allow the user to print the record
else
  //give user a warning

关键是,每个“角色”都必须是唯一的,你不能有一个通用的“编辑”角色,因为如果你有一个具有相同 ID 的客户和供应商,并且你想看看用户是否有权限“编辑”,您可能会得到错误的结果。因此,有一个名为“编辑客户”的角色和另一个名为“编辑供应商”的角色。

在我看来,该解决方案无法很好地扩展,但对于只有数十条需要保护的记录的数据库来说,它工作得很好,并且易于实现和维护。它也不是以真正的关系方式设置的,即权限表中的 ObjectId 不与供应商或客户表相关。

(另外,在这种情况下,我的用户对象知道它是否是管理员,管理员不需要权限设置,可以访问所有内容,因此不需要权限搜索 - 节省了几纳秒的时间)

Given that you will have a very small number of customers and suppliers (20 total), you don't need a very complicated system.

What I have done in similar situations is have a permissions table setup with a structure like this:

  • UserId (the users id )
  • RoleId (an id that links to a role table, with things like "Edit Customer", Delete Supplier", view customer
    etc. )
  • ObjectId (this would be the id that identifies whatever
    object you want to secure, so either the supplier id or customer id.)

The role table would have:

  • Id (unique id relates to RoleId in the permissions table)
  • Name (unique name of the role, i.e. 'Edit Customer')

Then each user entity is linked to a table of permissions, each user has multiple permissions. When a user logs in, I generally would choose to load all their permissions into an in memory list, so a user would have a list of permissions. The permissions list would have just the ObjectId, and the RoleName and/or RoleId (I tend to use rolename to make the code easier to read as you can see below in the example)

protected bool HasPermission(long ObjectId, string RoleName)
{

//Users in the Administrator role have access to everything in the system.
if (this.IsAdministrator) {
    HasPermission = true;
    return;
}

foreach (Permission P in Permissions) {
    if (P.ObjectID == ObjectID & P.RoleName == Role) {
        HasPermission = true;
        return;
    }
}
return false;

}

then, if I want to know if a user as permission to something I would do this:

if (myUser.HasPermission(CustomerId, "Edit Customer") {
  //allow the user to edit the customer
else
  //allow the user to only view the customer (for example)

or

    if (myUser.HasPermission(SupplierId, "Print Supplier") {
  //allow the user to print the record
else
  //give user a warning

The key is, that each 'role' needs to be unique, you can't have a generic 'Edit' role, because if you have a customer and supplier that have the same id, and you want to see if the user has permission to 'Edit', you may get the wrong result. So have a role called 'Edit Customer' and another role called 'Edit Supplier'.

This solution wouldn't scale well imo, but for a database with just dozens of records that need to be secured, it works just fine and is simple to implement and maintain. It is also not setup in a truly relational way, i.e. the ObjectId in the permissions table is not related back to either the supplier or customer table.

(Also, in this scenario I my user object knows if it is an administrator or not, administrators don't need permissions setup, the have access to everything, so no permissions search is needed - saves a few nanoseconds of time)

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