问题描述
|
我正在做一个Django电子商务项目，在此项目中，我同时拥有一个Customer模型和一个Merchant模型。 Merchant模型与MerchantStore模型相关联，该模型某种程度上“很复杂”，具有大量的m2m和与各种模型的外键关系。
按照本文中的解决方案，并且没有足够的“时间”来进行自定义实现，我决定让每个商家成为“工作人员”，并通过管理界面自定义其商店。当然，我创建了一个具有适当权限的新组。
但是，会出现一些问题：
1）这被认为有害吗？是否存在任何相关的安全威胁？
2）如果您没有足够的时间，这不是最好的方法吗？
解决方法
不，我不会认为这有害。
如Apress的djangobook中所述，“管理员的禅宗”似乎暗示了对信任的假设，并将其作为管理员的“哲学”的一部分，并且与经常重复出现的“管理员不是您的管理员”配对应用建议”，一开始我也很害怕，并且认为Django文档可以指出预期的可行用例。
请为最终用户查看我几乎相同的问题Django AdminSite / ModelAdmin？
从乔丹的回答（我给了我赏金）：
本质上没有什么特别的
关于管理员。它的行为就像任何
其他观点。所以如果使用
确定访问权限（针对
例如，如果您设置了用户的.is_staff
设为True，但仅授予他们访问权限
特定权限），那么它将是
对您可能使用的任何视图同样安全
创建使用权限来
确定访问权限。
...
写的人
django.contrib.admin没有写
假设任何人
is_staff = True可以被信任为
就像超级用户一样，或者是愚蠢的
足以永远不要看
网页的源代码。虽然
鼓励您发表自己的看法，
它仍然是一个健壮的界面。
还要注意Django的相对较新的安全更新http://www.djangoproject.com/weblog/2010/dec/22/security/
关于对象列表中的querystring参数。
这样的更新（引用：“有权访问管理员的攻击者”）清楚地表明，管理员对许可系统的实施正在受到严格审查。
,是的，这被认为是“有害的”，主要是由于Django开发人员的设计考虑。管理员围绕“受信任的用户”的概念。换句话说，如果某人是工作人员（从而可以访问管理员），则他们大概拥有您的信任，不必担心安全漏洞。现在，实际上，您可以将它们从不应引起混乱的部分中阻止（如您所做的那样），但要点是Django在此方面不做任何保证。实际上，您可能不会有任何问题，但是可以。
具有讽刺意味的是，我认为自定义Django管理员花费的时间比我从头开始构建它要花费更多的时间。真有趣。不管怎样，我都希望它在Ruby on Rails中使用脚手架。这是使某些内容生效的快速方法，但目标是尽快将其替换。