我们一直在重构我们基于Web的管理应用程序（再次），并且在描述我们以前调用CRUD（create-read-update-delete）操作所涉及的权限时遇到了一些困难。我们发现，仅仅尝试描述CRUD方面的操作/权限并不真正适用于Web应用程序。似乎CRUD作为一个概念分散在数据范围内 - 无论是在数据库中还是在应用程序模型中：
Scope Permissions Example
----- ----------- -------
Table READ I can view a list of all orders
Row READ | CREATE | DELETE I can view an individual product, I can create a new product and I can delete it from the database
Field READ | UPDATE I can view and update a customer's username
我们正在努力想出一个简洁的权限表而不会混淆范围。例如，如果我想创建一个新产品，我必须有权访问READ产品表，READ和CREATE产品行，并且还具有对产品名称字段的READ和UPDATE访问权限...所有这些都加起来一个非常混乱的权限树！目前，我们在整个地方都有愚蠢的方法，例如hasAccess($object, $user_ID)和if / else语句中的嵌套'n'级别，以满足上述情况。
是否还有其他众所周知的方法来描述用户权限而无需借助CRUD？
感谢您的帮助！
（并且，在你问之前，是的，我们已经查看了很多框架，看看他们是如何做到的，不，我在文档中看不到我的例子！）
答案 0 :(得分：1)
您已经描述了数据库层类型的安全模型 - 这种方法很有效，特别是如果您可以从应用程序外部直接访问数据库。
如果您没有外部数据库访问权限，则可以考虑在业务对象上创建安全性，而不是在数据模型对象上创建安全性。
在您的示例中，您将为PRODUCT创建一个类，并提供类似CREATE的权限，这意味着下一层（数据层）中的各种级别的实际权限。
如果某个管理员使用命令行可能会导致数据损坏，那么您可能希望坚持使用数据库级别约束来始终确保完整性。