I have added row level permissions with django-guardian to my project.
From the set-up it seems everything worked fine:
Guardian specific tables have been created (guardian_groupobjectpermission, guardian_userobjectpermission)
Models with GuardedModelAdmin show the "Object permissions" feature next to "History"
It lets me assign "Add", "Change", "Delete" permissions for users/groups
But assigning (resp. not assigning) permissions shows no impact at all on the admin interface. Every user is allowed to do everything with all objects.
I have tried with
user_can_access_owned_objects_only = True
but this only affects the ability to view objects. Once a user sees it, he can also change and delete it. Regardless what is set in the permissions.
And I followed another discussion suggesting this in the ModelAdmin
def queryset(self, request):
if request.user.is_superuser:
return get_objects_for_user(user=request.user, perms=['change_program'], klass=Program)
But this has a similar effect as above, it only limits the visible items.
I would have hoped to see the admin "save" and "delete" buttons (and functions) listening to django-guardian. Is this a misunderstanding? Or did I simply not walk down the entire road yet?
Thanks for any hint!
R
Guardian allows you to create your own permissions to assign to user/object combinations, but limiting access to resources based on those object permissions still requires you to write code in your views. As such, there is no automatic enforcing within the Admin views. The admin integration is for allowing users with access to the admin interface to manage object-level permissions, see the guardian docs:
http://django-guardian.readthedocs.org/en/latest/userguide/admin-integration.html
Related
I am building an intranet site for my organization with Wagtail and we are in the process of adding a knowledge base. The entire site needs to be restricted to logged-in users, but certain pages need to only be accessible to users in certain groups. For instance, only members of the IT group should be able to access the pages underneath the IT Knowledge Base page.
Currently if I set the top-level page to be accessible only by logged-in users, that permission is applied to every page on the site, and I am barred from setting more specific permissions on any child page. It is imperative that I be able to set more specific permissions on child pages.
I was able to find Wagtail Bug #4277 which seems to indicate that the logic for more specific permissions is implemented but not exposed in the admin UI.
I am not familiar with the inner workings of Wagtail yet, especially how Wagtail permissions intersect with Django permissions. How can I add more specific permissions to child pages?
You can restrict or allow users to view a site. You can also restrict or allow users to do some actions (maybe modifying an article).
To pass these restrictions or allowances django uses groups and permissions. Basically it all is based on permissions but sometimes you want to pass the permission to an entire group rather than passing permissions to users explicitly.
Therefore you could create your it_group. Then you would add the permission, let's call it it_permission to that group. When you then add a user to that group, that user then has all the group permissions. As said you don't need to organize these steps with groups. You could also add a permission, let's call it admin_status to a user directly.
When you build your views there are multiple operators that check for permissions of currently logged in user.
You could decorate your view with the permission-required-operator.
See the example:
from django.contrib.auth.decorators import permission_required
#permission_required('your_user_app.it_permission')
def my_view(request):
# only users with permissions can view this view.
Django and Wagtail are both awful at object authorisation.
For your case, it depends how tight you want to make the security, and how complex the authorization model is.
You can set permissions on a per page basis via the group edit page in the admin menu, any page below will inherit those permissions. The problem with this is that the least restrictive permissions apply and there is no deny option. If they have edit permission on a parent page, they'll have edit permission on the child page.
If you just want a superficial prevention to stop unauthorised people editing all knowledge base pages, you might look at using hooks to assess the permissions of the logged in user.
You can use before_edit_page to check before the page form is rendered for editing and redirect to a notification page if they fail, or use after_page_edit to prevent saving (not very friendly after the editor has spent some time on the page).
For before edit, for a simple one-off case and where there is a class for the KB page, where you want to allow only members of the IT Department and Site Managers groups to have access, it could be something like:
# wagtail_hooks.py
from django.contrib import messages
from django.http import HttpResponseRedirect
from wagtail import hooks
from kb.models import KnowledgeBasePage
#hooks.register("before_create_page")
#hooks.register("before_delete_page")
#hooks.register("before_edit_page")
def check_kb_permissions(request, page, page_class=None):
if (page_class or page.specific_class) == KnowledgeBasePage:
if not request.user.groups.get_queryset().filter(name__in=['Site Managers','IT Department']).exists():
messages.error(
request,
'You do not have permission to add, edit or delete knowledge base articles.\
<br><span style="padding-left:2.3em;">Contact support \
to report this issue</span>'
)
return HttpResponseRedirect(request.META.get('HTTP_REFERER', '/admin/'))
If the user fails, they stay on the same page with an error message in red banner at the top of the page.
You can build this out to a more complex authorisation model, matching user groups with models and permissions if need be, rather than the hard coded example above.
This doesn't affect CRUD permissions for programmatic operations, but if your concern is just the editor interface then this works.
I have designed my own RBAC system for my Django app. Unlike the original Django's role-based that uses only permissions, content_types, groups, and users table, I designed mine so that it includes a model for defined operations (i.e. read, write, print), the objects (i.e. Post, Events, Documents), the roles (Writer Level 1, Events Manager) and the necessary relationships i.e. my own permissions table which takes in the object reference and a matching operation reference (i.e. Post | add).
My problem now is I am not quite sure how to implement this in DRF. When I use permission_class = (DjangoObjectPermissions,) and someone sends a 'POST' request to the Post model/table, we all know Django will check if the user has Can add post permission. I want to do this as well but I want Django to refer to my RBAC models/tables.
I want to write my own permission classes in my permissions.py but I might need a bit hint on how to implement this.
I've read you can create custom permissions, but I am not sure if that also means you can enforce your own RBAC tables with it.
Alright after checking rest_frameworks' permissions.py, I think I can enforce my own permission class behavior this way:
Create a custom permission class that subclasses rest_framework.permissions.BasePermission
override has_object_permission() method
Inside the method, write a logic that maps the requesting user into my custom RBAC models to check whether or not he has given the appropriate permission
Return the appropriate boolean
According to the DRF Permissions doc
As with DjangoModelPermissions, this permission must only be applied to views that have a .queryset property or .get_queryset() method. Authorization will only be granted if the user is authenticated and has the relevant per-object permissions and relevant model permissions assigned.
So, you should define either queryset attribute or get_queryset(...) method in your view class.
Example:
class MyViewClass(viewsets.ModelViewSet):
queryset = SomeModel.objects.all()
...
...
...
def get_queryset(self):
return SomeModel.objects.filter(some_field='foo')
...
...
...
The permissions to a User or groups can be controlled via Django's Admin site as well as Django shell
Django 1.11.2
django-registration-redux==1.6
I'm building an intranet website. And I'd like to control myself whether users are active or not. In Django admin there is such a possibility. But "Active" attribute is set to True automatically when a newly registered user confirms his/her email.
In other words what I'd like to do:
1) Let users register and reset passwords.
2) Admin of the site assigns the new user to a group. Users with the minimum permissions can only view. Special permissions allow edit, delete etc. But the user must be unable even to view anything without approval by the admin.
Now I'm planning to organize can_view permission for every model. The two above conditions will be performed by assigning the user to a group.
Well, this seems to be rather cumbersome. That "Active" attribute in admin is much more elegant. But "Active" is automatically set to True when the user confirms his/her email.
Could you give me a piece of advice here?
While it's tempting, never use is_active to deny permissions. The flag is meant to be equivalent to "deleting a user". That also means the user cannot login (with default authentication backend). So it's not an authorization guard, but an authentication guard.
That said, if you don't grant permissions, users don't have them. So if you implement can_view and set it to guard the relevant models and views, then the user can log in, but cannot see anything you don't want them to (it's convenient for a user to see that she successfully logged in though :) ).
Follow-up question from comments
It's fine to use one global permission that is checked per view. When using class based views, I recommend extending LoginRequiredMixin, tuck a few other goodies in a IntranetCommonMixin and have each view combine it with one of the generic base views. See also my answer here.
The only reason you don't want to do it, is that it's tough to code exceptions on the rule, because the first "object" that says "yes", wins.
What I would like to do is to set view permissions of certain parts of the site depending on the user (that is easy using permissions and guardian).
I have a set of buttons across the top of the page. For one or two buttons I want to set permissions for only a few users or groups to be able to see that button. That part is fine (using guardian).
Each button is related to a model instance. The model has a view_button permission. Is there a way to have the view_button permission be default to True if the permissions is empty? Or, is there a way of saying has_perm be True for all users?
Maybe I could just create a static method within the model that does that check for me. Is there a better way to do it?
As far as I know, there are 3 permission levels available to use in django (whether by django itself or by using 3rd party apps).
1) Model-based permission
2) Object based permission
3) Row-based permission
It would be great if you tell me the exact differences between these 3 levels of permission system.
Not sure where you got that info, but it's not even remotely correct. Django technically doesn't have any permission system. The auth contrib app adds a system of "permissions" but it's optional and could be replaced entirely with something else. The admin app (also a contrib package, and optional) uses auth, so if you're talking about the Django admin, or using the auth package with your own app(s), then we can talk.
In auth, you have Users, Groups and Permissions. Users come in either "superuser" or "regular" user flavors, and every model in your project gets three Permissions automatically when you run syncdb (with auth included in INSTALLED_APPS): can_add, can_change, and can_delete. Users marked as "superusers" (is_superuser == True), can take any action on any model. Other users need to have Permissions explicitly assigned to them. Further, Groups may have Permissions assigned to them, and then, any User assigned to that Group inherits those permissions.
So, a user could have no ability to do anything with any model, some combination of add, change or delete capability with some or all models or complete access to do anything with any model. There's no concept of "object-based" permissions, in the sense of an "instance". You can either either edit every instance of an model or none. There's also no concept of "row-based" permission. A row in the database table is merely an instance of the model, anyways.