具有细粒度访问控制的Django身份验证 [英] Django authentication with fine-grained access control
问题描述
我正在使用针对结构工程师的一套钢设计工具来开发Django Web应用程序.每个设计工具都有一个数据库输入表，每个表的每一行将对应于要解决"的特定设计条件.用户可以单独工作或成组工作.每个用户都需要不断访问自己的工作，以便可以完善，复制和改编设计，以便可以在方便时创建报告，通常是在项目结束时需要硬拷贝文档的时候.然后，对于给定的设计项目，数据库内容必须在以月甚至数年为单位的一段时间内的任何会话中都可用.
I am developing a Django web application with a suite of steel design tools for structural engineers. There will be a database table of inputs for each design tool, and each row of each table will correspond to a particular design condition to be "solved." The users may work solely or in groups. Each user needs to have ongoing access to his own work so that designs can be refined, copied and adapted, and so that reports can be created whenever convenient, usually at the end of a project when hard copy documentation will be needed. The database contents must then be available over any number of sessions occurring over periods measured in months or even years for a given design project.
当存在一组用户时，通常都是与给定设计部门相关联的用户，对于他们所有人来说，可以共同且相互访问彼此的工作可能是可以接受的.该应用程序支持常规的工程生产活动，而不是创新的知识产权工作，并且内部隐私仍然不是行业中的常态.但是，绝对不能将作品遮挡在团队外部.理想情况下，每个组将具有一个或多个被授权管理该组成员身份的超级用户.他们可能需要的主要工具是能够从组中删除成员，并终止其访问权限.这将是用户组的超级用户，并且与站点侧的超级用户不同.
When there is a group of users, typically all associated with a given design office, it will probably be acceptable for them all to have joint and mutual access to each other's work. The application supports routine engineering production activities, not innovative intellectual property work, and in-house privacy is not the norm in the industry anyway. However, the work absolutely must be shielded from prying eyes outside of the group. Ideally, each group would have one or more superusers authorized to police the membership of the group. Probably the main tool they would need would be the ability to remove a member from the group, discontinuing his access privileges. This would be a user group superuser and would not be the same as a superuser on the site side.
为了方便访问，每个数据库表的每一行都将与一个项目编号/项目名称对关联，这对给定部署用户或用户组的公司来说是唯一的.另一家公司可以轻松地选择使用重复的项目编号，甚至可以选择重复的项目名称，因此要准确地区分哪些数据库行属于给定的用户(或组)，可能必须在单独的相关所有权列表"中进行跟踪. 表(用于每个用户(或组)).
For convenient access, each row of each database table will be associated with a project number/project name pair that will be unique for a given company deploying a user or user group. A different company could easily choose to use a duplicate project number, and even could choose a duplicate project name, so discriminating exactly which database rows belong to a given user (or group) will probably have to be tracked in a separate related "ownership list" table for each user (or group).
预计(希望)最终，与不同(且经常竞争)的公司相关的数百个用户(或用户组)将使用这些工具解决成千上万个项目的数万个设计条件.
It is anticipated (hoped) that, eventually, several hundred users (or user groups) associated with different (and often competing) companies will solve tens of thousands of design conditions for thousands of projects using these tools.
所以，这是我的问题:
首先，尝试从Django contrib.auth代码中挽救很多东西有什么意义吗?据我所知，contrib.auth是为身份验证和访问控制而设计的，它适用于Blogosphere和Web新闻，但不支持对内容"访问的细粒度控制.
First, is there any point in trying to salvage much of anything from the Django contrib.auth code? As I perceive it, contrib.auth is designed for authentication and access control that is suitable for the blogosphere and web journalism, but that doesn't support fine-grained control of access to "content."
第二，是否有任何适用于此问题的模板，模式，示例，策略或设计建议?
Second, is there any available template, pattern, example, strategy or design advice I could apply to this problem?
