Django AdminSite / ModelAdmin为最终用户？ [英] Django AdminSite/ModelAdmin for end users?

问题描述

并不是所有的软件都不需要左侧的内容制作人的管理界面，右边是访客/会员的网站。

经常说管理员不是你的应用程序（参见例如接受的答案（2009年3月））。

我在Django文档中找不到这样的限制。
似乎有以下假设： a强大的生产就绪界面，内容制作者可以立即使用它来开始向网站添加内容 - 但当然预期，甚至在常见问题解答中提到。还有另外一个用于多个AdminSite实例的用例？

我正在开发一种主要是CRUD界面的软件。每个用户都必须进行身份验证，并且管理员用户和客户之间的唯一区别在于后者只能使用他们的对象（而不能访问某些型号，如用户等）。 顺便说一句，我们的案例不是与谁创建对象相关，而是与其相关联的公司。

有没有任何令人信服的理由不要坚持使用管理界面，只需配置正确的权限鸡尾酒？ ModelAdmin权限是否可信？为什么不只是调用所有登录的用户工作人员？

对于传统的非管理员视图，我看到自己重写了什么似乎已经存在：ModelForm是一个很好的开始，但是CRUD功能和类型依赖的过滤器（包括日期向下钻取）是不容易获得的组件。管理员的功能已经提供了绝大多数终端用户需要的功能，并且字段/过滤器/模板等的定制足以满足我的需要。显然，我添加了一个新功能，例如其按钮的可视性和对相应视图的访问需要权限检查。我不担心我只是好奇，无论是在这种情况下，管理功能被其内置的一组权限正确覆盖。有什么经验吗？

更新：对不起，这个问题的主要部分似乎不清楚。我不担心我的自定义，我担心信任现有的管理应用程序及其权限的实现。另见对Daniel和FallenAngel的评论。

解决方案

我们有一个刚刚运行的系统。
$ b

程序有一个基本的用户登录，这是一个基本站点，并使用手写的视图和模板（因为它需要）...有一个客户部分，这是具有有限访问权限的基本管理页面。而且，管理员是我和像我一样的人。

逻辑是，管理员是在公司工作的人，谁可能拥有所有访问权限权限（超级用户为sjango说）或对应用程序的访问受限，但可以看到所有相关的DB记录。客户是我们销售我们的程序的人，他们对管理员的访问有限，只能看到与他们相关的记录。用户是我们的客户...

在这一点上，django权限是不够的，因为我们的客户必须看到记录属于他的帐户，而标准管理员可以查看所有记录。这两个可以根据他们的权限到达应用程序。超级用户可以看到和做任何事情...

对于解决方案，而不是usnig django站点应用程序（我从来没有使用，没有太多的信息），我们创建了一个模型扩展Django用户，其中有一个像角色这样的字段是用户角色是系统管理员，那么他可以看到所有的东西（如果超级用户，否则他正常使用权限）...如果没有，他可以达到

所以，几乎每个数据库表都必须有一个外键定义相关记录的所有者公司。

如果需要，您可以过滤属于特定公司的记录...

在我的模型中，我有Kullanici继承用户模型

  class Kullanici（User）：
 rol = SmallIntegerField（）＃1如果系统管理员， cusotmer等... 
  

然后，我写了一些方法来覆盖管理方法，like; ModelAdmin.save和modelAdmin.queryset 进行以下检查...

  #override admin queryset方法
 def override_queryset（obj，req）：
 qs = super（type（obj），obj）.queryset req）
 kullanici = Kullanici.objects.get（id = req.user.id）
如果kullanici.rol == 10：
返回qs 
返回qs.filter（site = kullanici.site）
  

所以，当用户转到应用程序的列表视图时，他只看到与他相关的网站，其他记录不会显示，或者如果他尝试去记录属于其他网站，他将获得Permisson错误。这些都是django贝司控件，所以你可以确定他们不会达到他们不能的ant记录。

你必须覆盖所有需要过滤的管理方法属于客户。

为了进一步限制，我使用一个函数来显示/隐藏模型的字段。在admin .py文件中：

  class SomeModelAdmin（ModelAdmin）：
 exclude = [] 
 def changelist_view（self，request，extra_context = None）：
 extra_context = {'exclude'：['field1'，'field2']} 
 return get_admin_listview（self，request，extra_context）
 
 
 def get_admin_listview（obj，req，extra）：
 system_admin = Kullanici.objects.get（id = req.user.id）.rol == 1 
如果不是system_admin： 
如果extra.keys（）中的exclude：
为额外的['exclude']键：
如果键不在obj.exclude中：
 obj.exclude.add （键）
  

您提供要隐藏的字段名称列表，如果用户不是系统管理员...

手段是，django管理缓存可能会导致，发生在我一次或两次在8个月。其他重要的部分是，您不能限制管理员筛选器，因此如果您有一个需要有限访问权限的筛选器，则无法过滤筛选器。您可以使用所有选项显示它，也可以不使用它。

如果这种方法解决了您的问题，我可能会写一个更详细的信息...

更新：是的，权限系统简单安全，如果您检查 permission_required decorator 从最新的中继线代码...

逻辑简单，用户具有相关的权限，相关视图也被隐藏。否则相关视图或代码根本不执行。所以，Permissons为django管理员提供了足够的安全性。
权限控制可以在视图级别和/或模板级别上使用。

必须谨慎的一点是手写视图，其中不安全的代码可能导致严重的问题，但这是关于您的编码，这是您将面对的每种框架和编程语言的一种安全风险...

最后问题的关键在于django和admin查看页面的过滤机制。由于几乎所有的管理过滤器都使用GET过滤数据，并将id传递给显示特定记录的URL。 django书的Seciruty部分显示有关可能的安全问题的基本信息以及django如何处理它们...另一方面手， 2010年12月22日的安全更新显示了一个这样重要的漏洞，需要足够的关于模型的信息结构。

Not all software has the need for an admin interface for "content producers" on the left and a site for "visitors/members" on the right.

It is often said that "the Admin is not your app" (See for example the accepted answer (March 2009)).

I couldn't find such a limitation mentioned explicity in the Django documentation. There seems to be an underlying assumption of the above - "a powerful and production-ready interface that content producers can immediately use to start adding content to the site" - but different levels of access are certainly anticipated, even mentioned in the FAQ. And what other use case for multiple AdminSite instances anyway?

I'm currently working on a software which is mainly a CRUD interface. Every user must be authenticated, and the only difference between admin users and customers is that the latter can only work with "their" objects (and no access to certain models like "User" etc.). By the way "their" in my case not related to who created the object, but rather which "Company" its associated with.

Is there any compelling reason not to just stick with the admin interface, and just configure the right cocktail of permissions? Can the ModelAdmin permissions be trusted? Why not just call all logged in users "staff"?

For traditional non-admin views I'm seeing myself re-writing what seems to already be there: A ModelForm is a nice start but CRUD functionality and type-dependent filters (incl. date drill-down) are not readily available components. The functionality of the Admin already provides the vast majority of the features that end users need, and customization of fields/filters/templates etc. is sufficient for my needs. Obviously where I add a new feature, e.g. visibility of its button and access to the corresponding views needs a permission check. I'm not worried about that. I'm just curious whether in a case like this the Admin functionality is properly covered by its built-in set of permissions. Any experiences with that?

UPDATE: Sorry the main part of this question seems unclear. I'm not worried about my customizations, I'm worried about trusting the existing admin app and its implementation of permissions. See also comments to Daniel and FallenAngel.

解决方案

We have a system that just runs as you asked.

Program have a basic user login, which is tha basic site and uses hand written views and templates (as it needed to be)... There eexists a Customer part, which is the basic admin page with limited access rights. And there is admin whom are me and people like me.

Logic is, admins are people working in the company, who may have all access permissions (superusers as sjango said) or limited access to the applications but can see all related DB records from those they have access. Customers are people who we sell our program, they have limited access to the admin and can only see records related to them. users are customers of our costumers...

In that point, django permissions are not sufficient, because our customer must see record belong to his account, while a standard admin can see all records. These two can reach applications according to their permissions. Superuser can see and do anything...

For the solution, instead of usnig django site application (which i never used and do not have much information) we created a model that extends Django user, which have a field like role is user role is System administrator, then he can see everything (if superuser, otherwise he uses permissions as normal)... If not, he can reach records relatred to their website (Company in your situation).

So, nearly each database table must have a foreignkey defining owner company of the related record.

By that, you can filter records belong to a specific company if required...

In my models, i have Kullanici that inherits User model

class Kullanici(User):
    rol = SmallIntegerField()# 1 if system admin, 2 if cusotmer etc...

Then, i write a few methods to that overrides admin methods, like ;ModelAdmin.save and modelAdmin.queryset that do the following check...

#override admin queryset method
def override_queryset(obj, req):
    qs = super(type(obj), obj).queryset(req)
    kullanici = Kullanici.objects.get(id=req.user.id)
    if kullanici.rol == 10:
        return qs
    return qs.filter(site=kullanici.site)

So, when a user go to list view of an application, he only sees sites related to him, other records will not be shown, or he will get permisson error if he tries to go to a record belong to some other site. These are all django bassed controls, so you can be sure they will not reach ant record that they must not.

You must override all Admin methods that require filtering belong to customer.

For further limitation i used a function to show/hide fields of the model. In the admin .py file:

class SomeModelAdmin(ModelAdmin):
    exclude= []
    def changelist_view(self, request, extra_context=None):
        extra_context = {'exclude':['field1','field2']}
        return get_admin_listview(self, request, extra_context)


def get_admin_listview(obj, req, extra):
system_admin = Kullanici.objects.get(id=req.user.id).rol == 1
if not system_admin:
    if 'exclude' in extra.keys():
        for key in extra['exclude']:
            if key not in obj.exclude:
                obj.exclude.add(key)

you give a list of field names to be hidden, and it will hide them if user is not system admin...

Handycaps are, django admin caching may cause, which happened to me once or twice in 8 months. Other important part is, you can not limit admin filters, so if you have a filter that requred limited access, you can not filter the filter keys. You can either display it with all options or simply do not use it.

If this approach solves your problem, i may write a more detailed information...

UPDATE: Yes, permission system is simple and secure, if you check the source code of permission_required decorator from the latest trunk code...

Logic is simple, the user has relevant permisson, related view is ececuted. Otherwise related view or code is not executed at all. So, permissons provides enough security for django admin. Permission control can be be used both on view level and/or template level.

One point that must be carefull is hand written views, where insecure code might cause serious problems, but this is all about your coding, and this is the kind of security risk that you will face with on every framework and programming language...

Last point of issue is the filtering mechanism of django and admin view pages. Since Nearly all admin filters uses GET to filter data, and passes id's to urls for displaying a specific record. Seciruty part of django book shows basic information about possible security issues and how django handles them... On the other hand, 22 December 2010 security update shows a such important vulnerability, which requires enough information about model structure.

这篇关于Django AdminSite / ModelAdmin为最终用户？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！