如何在 Django 项目中拥有 2 个不同的管理站点?
我想在 Django 项目中有 2 个独立的管理站点。
我所说的分离是指 - 他们应该有单独的用户身份验证,他们应该管理不同的模型,并且具有不同的外观和 URL。
我想要这样做的原因是客户想要单独的部分来管理页面的 CMS 部分,并单独用作“后台”解决方案。
我考虑在我的项目树中制作一个 django.contrib.auth 应用程序的副本,以不同的方式命名并为它们使用单独的 admin.site.register()
调用。这样我就可以在每个模型中使用其他模型、不同的外观等。我不知道如何解决用户身份验证问题(我应该有不同的用户能够登录到 CMS,然后登录到 BackOffice) 。
以前有人碰巧这样做过,可以给我一些提示吗?或者我打算做的事情在设计上就是错误的?
I want to have 2 separate admin sites inside a Django project.
By separate I mean - they should have separate users authentication, they should administer different models, and have different looks and URLs.
The reason I want to do it is the customer wants separate section to administer the CMS part of the page, and separate to use as a 'back-office' solution.
I thought about just making a copy od django.contrib.auth appliaction in my project tree, naming it differently and using separate admin.site.register()
calls for both of them. This way I can have other models available in each one of them, diffrent looks, etc. I don't know how to solve the user-authentication problem (I should have different user to be able to log into CMS then into the BackOffice).
Anyone happened to do this before and could give me some hint? Or what I plan to do is just wrong by design?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(3)
您可以子类化 Django 的
AdminSite
(例如,将其放在项目根目录中的admin.py
中):至少从 1.9 开始,您需要添加 name 参数才能使其工作适当地。这用于创建反向 url,因此名称必须是 urls.py 中的名称。
然后,您可以在应用程序的
admin.py
中使用它,就像使用普通的AdminSite
实例一样:您还需要为其定义一些 url(在您的项目的
urls.py
):另请参阅:http://docs.djangoproject.com/en/dev/ref/contrib/admin/#adminsite-objects
You can subclass Django's
AdminSite
(put it eg. inadmin.py
in your project root):At least from 1.9 on you need to add the name parameter to make it work properly. This is used to create the revers urls so the name has to be the one from the urls.py.
Then you can use it in your app's
admin.py
the same way as you do with the normalAdminSite
instance:You also need to define some urls for it (in your project's
urls.py
):Also see this: http://docs.djangoproject.com/en/dev/ref/contrib/admin/#adminsite-objects
要在不同的 AdminSites 中注册模型,您只需创建 django.contrib.admin.sites.AdminSite 的不同实例, 看到这一点。
您会很高兴使用两个不同的管理站点来管理不同的模型并具有不同的模板。
对于身份验证和权限,您应该能够使用内置的 django.contrib.auth ,就像自定义权限一样(希望其他人能够在这里提供更多帮助)
To register models in different AdminSites you just need to create different instances of django.contrib.admin.sites.AdminSite, see this.
You will be good to go with two different admin sites managing different models and having different templates.
For authentication and permissions you should be able to use the build-in django.contrib.auth as is with custom permissions (hope someone else will be able to help more here)
我不确定我在这里报告的发现是否对坎德完全有帮助,因为除其他外,我不知道他是否不仅谈论两个管理站点,而且谈论两个数据库,每个数据库一个。这就是我的情况。我有了一个好主意,我希望我的一个应用程序(一个新应用程序)拥有自己的数据库和自己的管理页面。
但我遇到了 Bernhard Vallant 的 AdminSite 子类化方法的问题,尽管这似乎是正统且本质上正确的做法。我解决了这个问题。
这是我发现完全必要的 Bernhard Vallant 代码的 mod:
是的,我的意思确实是 name='anything',您选择的(只要它不是 'admin')。我已经用它来切换,每次都失败,没有分配除管理员名称之外的任何内容。
我遇到的症状是,当我添加第二个数据库并为其创建一个 myadmin,然后使用 myadmin.register(My_ModelA) 注册模型,然后查看两个管理应用程序页面时,我的新应用程序页面使用第二个数据库和 myadmin ,模型 My_ModelA 看起来不错,但我的旧管理页面显示其模型的死链接,当我单击应用程序的非死链接(使用旧数据库的旧应用程序)时,我得到了404 代码,表示该页面不存在。
另外,我不知道这很重要,但我做了一些不同的事情
Bernhard Vallant 在 urlconf 项目中所做的:
好吧,“someword”是无关紧要的——它是针对最终用户的外观,而不是应用程序或项目的名称。但关联的管理员是我的旧应用程序和旧数据库的管理员。请注意 autodiscover() 包含项。 Bernhard Vallant 链接到的文档中存在一些模糊的语言,涉及其在项目 urlconf 配置时的使用,因为 Bernhard Vallant 具有 myadmin 导入,但也引用了默认管理员。
对于 mynewapp 的 urlconf,我有:
尽管完全有必要在内部将 AdminSite 实例命名为“admin”以外的名称,但我必须补充一点,当需要使用一些 admin.ModelAdmin 子类来使 mynewapp 的 admin.py 文件变得更加有趣时,确实有必要使用 admin.ModelAdmin 作为父类。 myadmin 毕竟是 AdminSite 子类的实例。因此,我认为它与 admin.site 相同,而不是与 admin 相同。
对于像我这样的 NOOB 来说,这一切都非常令人困惑,因为小写的 admin 看起来像一个实例,而我不熟悉子类化实例。所以我认为事实并非如此。
I'm not sure that my finding, reported here, would have been entirely helpful to kender because, among other things, I don't know if he was talking not only about two admin sites but also two databases, one for each. That's my situation. I got the bright idea that I wanted one of my apps, a new app, to have its own database and own admin pages.
But I ran into a problem with the AdminSite subclassing approach of Bernhard Vallant, though it seems to be the orthodox and essentially correct thing to do. I resolved the problem.
Here's the mod to Bernhard Vallant's code that I found to be utterly necessary:
Yes, I do really mean name='anything' that you choose (as long as it isn't 'admin'). And I've toggled in and out with it and it fails every time without the anything-but-admin name assignment.
The symptoms that I acquired were that when I added the second database and created a myadmin for it and then registered the model with myadmin.register(My_ModelA), and went to look at the two admin app pages, the one for my new app that used the second database and myadmin and the model My_ModelA looked fine, but my old admin page showed dead links for its models and when I clicked there on a non-dead link for an app (an old app that uses the old database) I got a 404 code to the effect that the page didn't exist.
Also, I don't know that it matters, but I did something different from what
Bernhard Vallant did in the project urlconf:
OK, "someword" is irrelevant--- there for appearances with regard to the end user and not the name of an app or the project. But the associated admin is the one for my old app and old database. Note the autodiscover() inclusion. There's some murky language in the docs to which Bernhard Vallant linked regarding its use when the project urlconf is configured as Bernhard Vallant has it with the myadmin import but also with a reference to the default admin.
And for the urlconf for mynewapp I have:
Notwithstanding the utter necessity of naming your AdminSite instance internally to something other than 'admin', I must add that when it came time to jazz up the mynewapp's admin.py file with some admin.ModelAdmin subclassing, it was necessary to indeed use admin.ModelAdmin as the parent class. myadmin is after all an instance of a subclass of AdminSite. As such I gather that it's on a par with admin.site, not with admin.
This is all very confusing to a NOOB like me because admin, with the lower case, looks like an instance, and I am unfamiliar with subclassing instances. So I assume that it isn't.