当您使用 Djangoauth
时,始终依赖于session
识别用户的机制,而不是制作其他一些 id,例如uuid1()
(例如,当您需要在电子商务站点中的额外会话时除外HTTPS
)。
对于权限部分,您可以直接检查所有权,主要如Koliber Services所述。和之间Company
的关系对于权限检查的逻辑至关重要。有很多方法可以对关系进行建模,因此代码会有很大差异。例如:User
Contact
# a modeling way
User.company -> Company : an user belongs to a company
Contact.contributor -> User : a contact is contributed by an user, would be invalid is user is leaving the company
# could check accessibility by
can_view = contact.contributor.company_id == current_user.company_id
# another modeling way
User.company -> Company : an user belongs to a company
Contact.company -> Company : a contact info is owned by a company, does not share globally
# could check accessibility by
can_view = contact.company_id == current_user.company_id
can_view
什么时候False
,用户应该因为他的未经授权的尝试而得到一个 403 并被记录。
通常,上述方法足以保护内容(在 Django Admin 中还没有)。但是,当您有许多不同类型的权限检查甚至行权限检查时,最好使用一些统一的权限 API。
以 Django-guardian 为例,您可以简单地将公司映射到组,并assign
can_view
允许代表用户公司的组的联系人。或者,使用信号或芹菜任务创建联系人时对公司所有用户assign
的权限。can_view
此外,您可以使用/contact/1/edit/
而不是/contact/edit/?id=1
. 通过这种方式,该int(request.GET('id'))
部分被移动到 urlconf 之类r'^contact/(?P<pk>\d+)/$'
的,更少的代码,更清晰。