在Web应用程序中描述CRUD的更好方法？

我们一直在重构我们的基于Web的管理应用程序（再次），并且在描述涉及我们用于调用CRUD（create-read-update-delete）操作的权限时有点卡住。我们发现，简单地试图描述CRUD方面的行动/许可并不适用于网络应用程序。看来，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

我们正在努力想出了一个简洁的权限表，而不范围混淆。例如，如果我想创建一个新产品，那么我必须有权读取产品表，读取并创建产品行，并且还具有对产品名称字段的读取和更新访问权限......所有这些都添加到一个非常凌乱的权限树！目前，我们有各种各样的愚蠢的方法，如hasAccess($object, $user_ID)，并在if/else语句中嵌套'n'级以适应上述情况。

是否有其他众所周知的方式来描述用户权限而不诉诸于CRUD？

感谢您的帮助！

（而且，我可以告诉大家，是的，我们已经看过很多框架，看看他们是如何做到这一点，没有，我看不到文档在我的例子！）

来源

2010-08-29 boatingcow

你所描述的数据库层安全模型的类型 - 运行良好，特别是如果您从应用程序之外直接访问数据库。

如果您没有外部数据库访问权限，则可以考虑在业务对象上创建安全性，而不是在数据模型对象上创建安全性。

在你的例子中，你会为PRODUCT创建一个类，并且给予像CREATE这样的权限，这意味着在下一层（数据层）中有不同级别的实际权限。

如果您有可能使用命令行从某个管理员数据损坏，那么您可能希望坚持使用数据库级别约束来始终确保完整性。

来源

2010-08-29 22:41:00 Randy

我认为我们遇到的问题是数据库安全模型也进入了应用程序模型。我上面讨论的权限封装了域模型和业务对象。实质上，所有的安全性都必须发生在应用程序中，因为维护数据库和应用程序安全性以及任何外部访问都通过应用程序API进行路由将成为维护的噩梦。因此，我们在应用程序中仍然存在混乱的代码，因为CREATE产品可能允许访问另一个用户可能没有的某个用户的某些字段。 – boatingcow 2010-08-30 21:40:24

标记为已回答。最后，似乎没有办法避免嵌套的权限，像'create_product'这样的权限实际上是由多个“父”权限组成的，比如'edit_product_name'，'edit_product_description'等。诀窍在于管理涉及的许多名称。 – boatingcow 2011-09-20 09:03:28

在Web应用程序中描述CRUD的更好方法？

回答

相关问题