Question

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

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

使用硬编码限制的多重安全级别。 - 我认为这是最简单的，但我不认为这是一个好主意，因为那时安全级别列表似乎过于特殊。 I.E.，我将需要“这个用户需要看到屏幕x，y和z，但没有别的”，所以我们只需编写一个新的安全级别并对这些restirctions进行硬编码。更糟糕的是，需要解释每个硬编码的安全级别，否则更改级别的管理员将不知道他正在将其更改为什么。
带有屏幕的“自定义”安全级别，允许管理员选择每个自定义帐户可以看到的屏幕。 - 这是我理想的方法，但我试图在数据库级别对此进行概念化

对于＃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和2的混合 - 也许允许管理员创建自己的安全级别配置文件。但就复杂性而言，这就像两者中最糟糕的一样。：）

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

Answer 1

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

对于第二个变体，您可以实施role based security。表结构示例：

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绘制自己的颜色。

另一种变体（对我来说更好）是通过动作更改SCREENS。

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技术实现）。通过这种方式，您可以创建一个安全屏幕，超级用户将为某些角色提供访问权限，并将用户与一组角色相关联。

屏幕访问限制数据建模方法

1 个答案: