3

大家好，我需要一些建议...

我们在数据库中设置了某些权限，以便用户可以对应用程序进行某些级别的控制。禁用、只读和编辑。

我的问题是：是否有比编写安全方法/检查每页以根据允许的权限启用/禁用/隐藏/显示适当控件的更通用/更好的方法来处理应用于页面上表单元素的权限？

任何人都有以不同方式处理此问题的经验吗？

编辑：

我只是考虑了为需要安全性的每一层添加常量然后在用户类中添加一个 IsAuthorized 函数的可能性，该函数将接受控件所在表单中的常量，并返回布尔值以启用/禁用控件，这将确实减少了当/如果我需要修改所有表单的安全性时我必须打的地方的数量。

干杯!

4

4 回答 4

3

很抱歉在这里稍微偏离主题，但从我的错误中吸取教训：

有一次我正在开发一个简单的网络应用程序，我认为我应该设置 3 个安全级别：有限只读（公共）、读限制写（用户）、读写（管理员）。用户表具有一定的安全级别，并且一切正常……直到随着项目的发展，我需要更好地控制安全级别。这一切都始于一个用户，该用户需要的不仅仅是在程序的一个区域进行用户控制，而不是完全的管理员控制。

我应该做的是设置一个具有更好控制的可扩展系统，即使我一开始并不需要它。这会为我节省很多时间。

于 2008-11-11T23:01:48.480 回答
2

我认为有比您考虑的更多的可能性。

  • 隐藏/可见 - 字段是否可见
  • 空白/系统/未更改 - 系统最初是否将该值设置为空白，或设置为某些业务规则提供的值，还是保持原样
  • 只读/可编辑 - 用户可以更改值吗
  • 必填/留空/可选 - 字段必须不为空，或者假设它是空白的，它可以留空，或者它是可选的并且在任何情况下都可以为空

此外，您还需要考虑做出决定的许多因素

  • 角色 - 通常用户有 1 个或多个角色，这些角色可以允许或禁止不同的可能性
  • 状态 - 相关对象的状态通常控制哪些字段是可编辑的，无论角色如何
  • 对象 - 通常对象本身的值决定什么时候被允许，而不仅仅是它的状态
  • 任务 - 您可能会将编辑内容分解为不仅仅是阅读和编辑
  • 部分 - 我经常想控制对象或屏幕的整个部分的设置，所有控件都继承这些设置，但如果需要可以单独覆盖它们

执行？首先，确保您对如何处理页面生命周期有清晰的认识。我的通常是这样的。

  • 获取他们正在编辑的对象，通常来自会话状态，有时如果他们正在执行“新”操作，您可能需要创建一个存根数据结构供他们使用
  • 如果这是第一次加载页面，将选项填充到下拉列表中，这通常是一个通用过程，只完成一次
  • 如果这是回发，则通过从控件中读取值来更新正在编辑的对象
  • 处理按钮点击等事件
  • 运行所有业务编辑，这些应该会改变他们正在编辑的数据结构
  • 根据您手头的所有数据更新控件的可见性和可编辑性
  • 使用来自正在编辑的对象的数据填充控件，包括验证消息或错误消息
于 2008-11-07T21:00:04.203 回答
2

您可能想检查 django 如何处理表单并验证它们。表单像模型一样被处理，它们有自己的类，因此它们的字段列表、验证规则和显示逻辑不再分散在视图、控制器和助手中。有了这样的结构，隐藏/只读/可编辑逻辑所属的位置就很清楚了。

似乎这样的功能还没有在 Rails 中实现。它不仅可以节省时间，还可以使您的代码保持整洁和结构化。您可以从为表单创建一个基类开始，其中验证与控制器是分开的。

于 2008-11-11T22:48:46.387 回答
1

为了正常工作，我发现访问级别应该按递增顺序排列：NONE、VIEW、REQUIRED、EDIT。

请注意，REQUIRED 不是您可能认为的最高级别，因为 EDIT（填充和取消填充权限）比 REQUIRED（仅填充权限）具有更大的权限。

枚举看起来像这样：

/** NO permissions.
 *     Presentation: "hidden"
 *     Database: "no access"
 */
NONE(0),

/** VIEW permissions.
 *     Presentation: "read-only"
 *     Database: "read access"
 */
VIEW(1),

/** VIEW and POPULATE permissions.
 *     Presentation: "required/highlighted"
 *     Database: "non-null"
 */
REQUIRED(2),

/** VIEW, POPULATE, and DEPOPULATE permissions.
 *     Presentation: "editable"
 *     Database: "nullable"
 */
EDIT(3);

从底层（数据库约束）创建要访问的字段映射。然后，此地图在下一层（业务规则 + 用户权限）得到更新（进一步限制）。最后，如果需要，顶层（表示规则）可以进一步限制地图。

重要提示：必须包装地图，以便它只允许在任何后续更新中减少访问。试图增加访问权限的更新应该被忽略而不触发任何错误。这是因为它应该像一个投票系统一样决定访问应该是什么样子。本质上，上述访问级别的后续分层可以以任何顺序发生，因为一旦所有层都投票，它将导致每个字段的访问级别低水位标记。

后果：

1) 表示层可以为数据库指定的只读 (VIEW) 字段隐藏一个字段（将访问权限设置为 NONE）。

2) 当业务规则说用户至少没有 VIEW 访问权限时，表示层不能显示字段。

3）如果数据库说它只是“必需的”（不可为空），表示层不能将字段的访问权限移动到“可编辑”（可空）。

注意：应该使表示层（自定义显示标签）通过读取访问映射来呈现字段，而不需要任何“if”语句。

用于设置显示的相同访问映射也可以在提交验证期间使用。可以编写通用验证器来读取任何表单及其访问映射，以确保已遵循所有规则。

（另见线程：控制对表单字段的访问的最佳实践）

于 2009-11-16T17:54:33.703 回答