Disclaimer: I asked the question also at Google+, but I'm not sure how active the community there is
I'm struggling with Django CMS' permissions, and the documentation remains unclear for me.
I have the following requirements:
All CMS pages should be available only for authenticated users
Editing shall only be allowed to staff
Some pages should be only visible to a certain group
I don't find the way to achieve this. Could you point me to the right combination of settings?
Here are some more specific questions:
How does the "Login required" in the page permissions form relate to the other permissions you can set on the page?
If once set a view restriction for "this and all children", how can I remove it on a child page?
Why does CMS_PUBLIC_FOR not have a value for "Authenticated users"?
Is there a way to just restrict viewing of all CMS pages to authenticated users without restricting by a specific group?
Would be great if anyone had some hints.
Thanks!
I found a solution myself now:
First I wrote a custom middleware that redirects all requests to Django CMS pages to the login. Then, I removed the “can view pages” permission from all groups and all global permissions for non-staff.
Finally I removed all view restrictions on the page root and set them only on the particular pages which should be restricted.
If you are interested about some more findings in Django CMS' permissions: I blogged some thoughts about it here: http://blog.webrunners.de/2015/09/08/django-cms-permission-pitfalls/
Related
I have an existing website that is a Django App.
I have installed Wagtail, and the Wagtail CMS is now accessible at www.example.com/cms. Wagtail is working correctly with my database, and all the existing users are visible when I go to settings and then users, in the wagtail CMS admin page.
I want to use Wagtail to add blog functionality to my website.
Requirements
I want any user to be able to create a new blog and add posts to their blog.
I want the blog created by a user to be visible at www.example.com/blogs/username/
How can I set Wagtail up to accomplish this?
I have checked the documentation at http://docs.wagtail.io/en/v1.9/ but could not figure out where to start with my modifications. I have also installed the example blog project (https://github.com/wagtail/wagtaildemo) but I was also unable to figure out how to accomplish 1 and 2 above from this.
Any complete answers, or general pointers, very welcome.
The permission model built into Wagtail supports this kind of setup: http://docs.wagtail.io/en/stable/topics/permissions.html
After creating the index page for a blog, you'd create a group (Settings -> Groups in the Wagtail admin) for that blog - possibly just containing a single user - and under the 'Page permissions' section, assign it 'add' and 'publish' permission on that index page. Permissions propagate down the tree from that point, and 'add' permission encompasses the ability to edit pages that you've created yourself, so this would have the effect of giving the user control over the subpages of their blog.
This doesn't quite match the setup you've described, since it involves an existing Wagtail admin user having to do the initial setup, rather than users creating their own blog. However, since all of this configuration is done internally by creating / updating standard Django models such as Group and PagePermission, it would be possible in principle to script this process - for example, you could implement a Django view for "Set up my blog" on your site front-end, which runs the following steps:
Create a BlogIndexPage under /blogs with a title/slug matching request.user.username (see https://stackoverflow.com/a/43041179/1853523 for how to create pages programmatically)
Create a user group (django.contrib.auth.models.Group) for the current user, and assign them wagtailadmin.access_admin permission (so that they can log in to Wagtail admin)
Create a wagtailcore.PagePermission object corresponding to the newly-created group and blog index page, and 'add' permission; and likewise for 'publish' permission
Im starting a project using Django CMS that has multiple sites being controlled from one instance of Django CMS. I have found the documentation for User Permissions and Group Permissions but didn't see anything by default about permissions depending on which site the user is on.
I want to be able to give user a group and have them only be able to login to a specific site(s). Im sure this is going to be possible by requesting the current SITE_ID but I just wanted to see if anyone could point me in the right direction of a plugin or middleware that might let me do this?
Any advice would be greatly appreciated.
I'm currently developing 2 different sites at the same time: one of them is a heavily customized django-admin interface, and the other a "stand-alone" website that will share it's database with the previous one .
Even though they are related, I'd like my users not to loosely identify between the two sites : they are both able to be independant of the other.
However, a problem arises when someone is logged in the "admin" site : when they go to the other website, they are automatically logged. Won't happen the other way unless I allow it though, as the admin site requires special permissions in the User model.
I already created an UserProfile that can differentiate an user of one of the sites or of the both.
So, knowing all this, how can I make sure that the customers of the admin site don't get to be authenticated when in the other web site (without, of course, logging them out from the first one) ?
Thanks !
EDIT : To format it better, here is what I got , summed up :
One admin application / site Both running
One related application / site on same server,
sharing settings and urls.py
If some is logged in admin, I want to require them to create a new session to log on [related site] : this, without logging them off the admin site.
What changes should I do to this configuration to achieve this ?
Put different SESSION_COOKIE_DOMAIN and SESSION_COOKIE_NAME for each appication. Hope this solve your issue.
SESSION_COOKIE_DOMAIN = 'site1.com' #site2.com for other
SESSION_COOKIE_NAME = 'sid1' #sid2 for other
I got subdomains setup via django-subdomains and the django sites framework but I got problem and that is that I don't know how I can link Users to have access to only a certain subdomain. For example user1 from company1 only has acces to company1.arandomdomain.com
Found the answer here How to get unique users across multiple Django sites powered by the "sites" framework?
In short you have to write your own authentication backend to check for they condition you need to check. See docs here https://docs.djangoproject.com/en/1.7/topics/auth/customizing/#writing-an-authentication-backend
In my case I had to check first if the user is an admin so he/she can go and otherwise I had to check the userprofile which is linked a site and match that to the current site.
I need to implement workflows in my Django-CMS application at work. But form the Django-CMS feature list, we can read:
Editorial workflow
Workflows for publishing and approval.
I tried to search for it and didn't find anything. I've search the Django-CMS documentation (http://docs.django-cms.org/en/latest/index.html) and couldn't find something there either.
Does anyone has a clue about Workflows in Django-CMS (especially for the pages system) ?
An update for 2016:
No Editorial Workflow in django CMS 3 (yet)
django CMS 3 (v3.3.2 as of today) has no editorial workflow. This feature was removed in version 2.3, and replaced by the concept of "simple publishing" (2 versions of content: draft, public). Read the related blog post from Divio for their motivation.
For version 3.5 there is some extended moderation support planned via an addon, as explained by Angelo Dini in a current comment on the original blog post from 2012. Don't bet on it, though.
Control over Editing
If what you want is, at least, some control over editing, e.g. "some users are allowed to create and edit only but can't publish changes", then you're in luck. It works as follows:
Control over editing goes with the following formula, it's a combination of 3 things:
"Staff" status + App permissions + CMS permissions
The first two are plain Django concepts (from django.contrib.auth, see the Django docs) and the latter comes from django CMS. All 3 play together, here's why:
Without "Staff" status no editing is allowed at all, no CMS toolbar for front-end editing is shown either. Note that this status cannot be set on a group, it must be set on individual users. (d'oh!)
Without all app permissions (cms, djangocms-, cmsplugin-, zinnia) assigned to the group (or user directly) there is no editing; the CMS toolbar will be shown and you can typically double-click on content to initiate editing, but django CMS will tell you that you have no permission.
Omitting some of the CMS permissions (e.g. create, publish) disables the buttons on the CMS toolbar. That's about it. There is no message instructing the user what to do or explanation about what is happening (acknowledged, it's difficult to provide a generic solution here), neither are emails or other notifications sent (of course, there is no such thing as an editorial workflow).
IOW, it's possible to split your users into groups and allow them to do just some specific things (editing only, publishing only, etc.), but the user notifications, a central concept to workflow implementions, are not available in django CMS v3.3.
EDIT: See "Editorial workflow for django CMS" in the django CMS developers G+ group for details and a demo of a related implementation.
When you turn on CMS_MODERATION in Django-CMS, you will get three icons next to each page in the page list view. From left to right, these control
whether changes to this page will require moderator approval
whether changes to this page's children will require moderator approval
whether changes to this page's descendents will require moderator approval
When you create or change a page, you will be able to save it, and preview the page or new version of the page on your site, but it will require moderator approval before the page or new version of the page is visible to end users.