Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Permission checks for change_override_url_urlnode and change_shared_fields_urlnode are broken. #117

Open
mrmachine opened this issue Oct 11, 2016 · 2 comments

Comments

@mrmachine
Copy link
Contributor

def has_change_shared_fields_permission(self, request, obj=None):
"""
Whether the user can change the page layout.
"""
opts = self.opts
codename = '{0}.change_shared_fields_urlnode'.format(opts.app_label)
return request.user.has_perm(codename, obj=obj)
def has_change_override_url_permission(self, request, obj=None):
"""
Whether the user can change the page layout.
"""
opts = self.opts
codename = '{0}.change_override_url_urlnode'.format(opts.app_label)
return request.user.has_perm(codename, obj=obj)

These checks are triggered on page types (polymorphic child models) where self.opts.app_label is something other than fluent_pages. But the permissions are only created for UrlNode model (which belongs to fluent_pages app).

permissions = (
('change_shared_fields_urlnode', _("Can change Shared fields")), # The fields shared between languages.
('change_override_url_urlnode', _("Can change Override URL field")), # Fpr overriding URLs (e.g. '/' for homepage).
)

It looks like this has been the case for a long long time. I can only guess that it has never been noticed because everyone is using superuser accounts (which have all permissions, even permissions that don't exist).

Or perhaps another more recent change has only recently surfaced the issue. When I try to create a page with a staff account, I am told to fix the errors below (but there are none). I assume the error is that the read only override_url field is (None) instead of an empty string, and because it's read only, no field is shown.

@mrmachine
Copy link
Contributor Author

I tried to work-around this issue by manually creating change_override_url_urlnode permissions for all my page models. Now staff accounts can create pages. But they are still unable to edit the override_url field on existing pages, even though they have the permission.

I traced this down to the fact that django-fluent-pages is doing an object level permissions check, which as far as I know will always return exactly zero permissions, unless some additional package package (e.g. django-guardian) is configured to handle object level permissions.

Here, we are doing an object level permissions check:

https://github.com/django-fluent/django-fluent-pages/blame/f079fd96bbe1d7e40d812b00e985ea3ff24220b4/fluent_pages/adminui/urlnodechildadmin.py#L201

Here, Django is returning zero permissions if obj is not None:

https://github.com/django/django/blob/617e36dc1ede2a311dfd03f18432b31cbfe4c0f7/django/contrib/auth/backends.py#L76-L77

Seems like django-fluent-pages should only be doing an object level permissions check if it knows object level permissions are configured and safe to use?

@mrmachine
Copy link
Contributor Author

On further investigation of object level permissions. I can't imagine it's even a useful thing to check object permissions for these two permissions at all? If I understand correctly, even though we give the user permission to change the override URL field for all our page models, we will also need to explicitly assign the same permission to every single user and every single page instance?

I think django-fluent-pages should not check object permissions in these two methods. Perhaps not anywhere, and certainly not when it isn't sure there is a compatible implementation of object permissions in use?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant