对于基于权限的web应用程序，Django是一个不错的选择吗？

Question

我已经探索了一个星期的Django的细节，喜欢我所看到的。但是我发现了一些。。与CRUD接口权限的细粒度控制相关的负面影响。

我正在写的是一个内部网客户端管理web应用程序。该组织大约有6层，我需要根据层限制对客户组的访问。不断扩大。我非常清楚我将如何做到这一点，但不确定我是否能够很好地将其集成到预构建的管理界面中。

我已经做了绝对零的Django开发否则我可能会有更好的主意，这是否会工作。如果生成的管理接口对这个项目毫无用处的话，我可能不会使用Django，但是正如我所说的，这里非常依赖细粒度的自定义权限。

Django是否允许我构建自定义权限/规则并将其无缝集成到管理CRUD接口中？

更新一：我想使用管理应用程序来减少生成CRUD接口的重复授权，所以是的，我认为这是必须的。

更新二：

我想描述一下这个项目所需的权限。

客户机可以属于一个或多个“商店”。全职员工应该只能在他们的商店编辑客户（即使他们属于另一个商店）。但是，他们不应该在另一个商店看到/编辑客户机。Casuals应该只能根据他们被登记的商店来查看客户（或者如果Casuals是以商店用户的身份登录的话——更有可能）。

他们上面的管理层需要能够看到他们管理的商店的所有员工，仅此而已。

高级管理层应该能够编辑所有员工，并授予其以下权限。

在阅读了django文档之后，它说您不能（自动地）为组的子集设置权限。只有整个小组。为此目的模拟您自己的权限是否足够简单？

Answer 1

ModelAdmin对象有has_add_permission、has_change_permission、has_delete_permission和queryset方法，这些方法可用于强制登录用户可以看到和修改的内容周围的权限-您可以创建一个子类，使用这些子类强制您想要实现的任何权限，并使用子类向admin应用程序注册所有模型。

但是，这完全取决于您的权限系统将如何工作-您的细粒度权限中具体的要求是什么？离admin应用程序的设计目标越远，需要做的工作就越多，但其中有很多钩子可用于实现自定义需求。这里有一个blog post from Luke Plant，它给出了一些不必深入挖掘就可以进行微调的示例。

它一定要基于admin应用程序吗？Generic views和ModelForms可以处理实现CRUD所涉及的许多乏味的部分，因此be wary太过依赖于定制admin这几乎是一个Django的传统，首先是挂上admin应用程序以及它能做什么和不能做什么，最初以为你再也不必编写任何代码；）

Answer 2

如果我正确地阅读了您更新的需求，我认为Django现有的auth系统是不够的。听起来你需要一个完整的ACL系统。

这个问题已经提了好几次了。试试在django+acl上搜索。

随机抽样。。。

几年前有一个代码项目的夏天，但我不确定他们到哪里去了。见http://code.djangoproject.com/wiki/GenericAuthorization

在djngoproject.org上有一张新的票可能很有趣：

• http://code.djangoproject.com/ticket/9444

dumpz.org上有一些有趣的代码片段：

• http://dumpz.org/274/模型.py
• http://dumpz.org/273/信号.py

。。。但是没有医生。

祝你好运！

Answer 3

Django许可系统完全是规则。每个模型都有一组默认权限。您还可以向模型添加新权限。

每个用户都有一组权限和组成员身份。单个用户可以拥有单个权限。它们从组成员中继承权限。

您的视图函数（和模板）可以在需要使用的任何粒度级别上轻松检查是否存在缺少这些权限的情况。

如果这还不够，Profile插件会为您提供更多的选项来定义“用户”及其功能、权限、角色、职责等

如果这还不够，您可以定义自己的身份验证方案。

---

重要的是不要试图定义用户的实际子集组，不要随便定义标题或角色。您永远不需要“为组的子集设置权限”。你需要有更小的小组。围绕人的子集定义的组。

Django的默认权限是模型访问权限，而不是模型内的行访问权限。另一方面，您的问题在于几个模型中的行子集：客户机、商店、员工、经理。

在这些项中需要一组基本的FK，并需要一些过滤器来对行进行子集。在使用默认管理页时可能会遇到问题。您可能需要自己的管理版本才能使用专门的筛选器。

---

如果你不能使用Django许可系统，你应该重新考虑你的用例。说真的。

[然而，Django REST接口完全是另一个禽兽，需要一些照料和喂养。]