0

我有一个具有用户名/密码的程序。每个用户都有一个“安全级别”，现在（因为我们仍处于应用程序的早期阶段），有两个选项：“管理员”和“关联”。在软件级别，对助理级别帐户有硬编码限制，对管理员级别帐户没有限制。

然而，我们需要比这更多的多样性。有些用户只需要访问应用程序中的一个屏幕，有些用户需要访问多个屏幕，等等。有很多不同的选项。这些是我想到的解决方案：

  1. 具有硬编码限制的多个安全级别。- 我认为这将是最简单的，但我认为这不是一个好主意，因为那样安全级别列表似乎太临时了。IE，我将需要“此用户需要查看屏幕 x、y 和 z，但仅此而已”，因此我们只需编写新的安全级别并对这些限制进行硬编码。更糟糕的是，每个硬编码的安全级别都需要解释，否则更改级别的管理员将不知道他将其更改为什么。
  2. 带有屏幕的“自定义”安全级别，允许管理员选择每个自定义帐户可以看到的屏幕。- 这是我的理想方法，但我试图在数据库级别上对此进行概念化。

对于#2，我认为我必须创建两个表：

Table: custom_user_permission
   | user_id | screen_id |
 --|---------|-----------|
 1 |      5  |        1  |
 2 |      5  |        2  |
 3 |      5  |        3  |
 4 |     12  |        1  |
 5 |      4  |        2  |

另一个：

 Table: screen:

   | id (PK) | screen_name |
 --|---------|------__-----|
 1 |      1  |   Screen x  |
 2 |      2  |   Screen y  |
 3 |      3  |   Screen z  |

我不知道这将如何在软件级别上解释，但是......也许不是第二个表，而是定义哪个screen_id适用于软件级别的哪个屏幕会更好。这将使“screen_id”成为数据库上的任意整数，使其难以阅读。

  1. 1 和 2 的混合- 也许允许管理员创建自己的安全级别配置文件。但就复杂性而言，这就像两者中最糟糕的一样。:)

有人有建议吗？我的想法是，这将是一个非常普遍的问题，对吧？

4

1 回答 1

1

我认为这取决于您的系统复杂性。如果系统没有那么多屏幕（少于 20 个）并且没有客户可以修改需求的情况，您可以硬编码所有权限。

对于第二个变体，您可以实现基于角色的安全性。表结构示例：

ROLES (ID, ROLENAME)
USERS (ID, USERNAME)
USER_TO_ROLES(ID_USER, ID_ROLE)
SCREENS (ID, SCREEN_NAME)
ACCESS_RIGHTS(ID_ROLE, ID_SCREEN, RIGHT(no access/readonly/....))

每个屏幕都根据当前用户角色和 access_rights 绘制自己，并与它们相关联。

另一个变体（我认为更好）是用动作改变屏幕。

ROLES (ID, ROLENAME)
USERS (ID, USERNAME)
USER_TO_ROLES(ID_USER, ID_ROLE)
ACTION (ID, ACTION_NAME)
ACCESS_RIGHTS(ID_ROLE, ID_ACTION, RIGHT(no access/readonly/....))

安全核心模块必须决定用户是否可以执行某些操作。每次动作调用之前都必须进行安全检查（可以通过 AOP 技术实现）。通过这种方式，您可以创建一个安全屏幕，超级用户将在其中授予某种角色的访问权限并将用户与某些角色相关联。

于 2013-08-02T21:02:35.390 回答