Question

嘿所有，我需要一些建议...

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

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

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

编辑：

我只想到为每个需要安全性的层添加常量然后在用户类中添加一个IsAuthorized函数的可能性，该函数将从控件所在的表单接受一个常量，并返回boolean以启用/禁用控件，如果我需要修改所有表格的安全性，这确实会减少我必须点击的地方数量。

干杯！

Answer 1

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

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

我应该做的是设置一个具有更好控制的可扩展系统，即使我最初并不需要它。这样可以节省我太多的时间。

Answer 2

我认为比你正在考虑的可能性更多。

隐藏/可见 - 字段是否可见
已空白/系统/未更改 - 系统最初是将值设置为空白，还是设置为某个业务规则提供的值，还是保留为原样
ReadOnly / Editable - 用户可以更改值
必需/ LeaveBlank /可选 - 不是空白的字段，或者可以保留为空白，假设它一开始是空白的，或者是可选的，并且在任何情况下都可以为空白

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

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

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

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

Answer 3

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

似乎这个功能尚未在rails中实现。它不仅可以节省时间，还可以保持代码清洁和结构化。您可以从为表单创建基类开始，其中验证与控制器分开。

Answer 4

为了正常工作，我发现访问级别应按此递增顺序：无，查看，需要，编辑。

请注意，由于EDIT（填充和解除许可权限）比REQUIRED（仅限填充权限）更高的权限，所以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）表示层CAN隐藏数据库指定的只读（VIEW）字段的字段（设置访问NONE）。

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

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

注意：应该制作表示层（自定义显示标签），通过阅读访问地图来呈现字段，而无需任何“if”语句。

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

（另见线程：Best Practices for controlling access to form fields）

控制权限的最佳做法？

4 个答案: