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

DjangoModelPermissions does not respect Django can_read_model permissoin #6324

Closed
5 of 6 tasks
paultiplady opened this issue Nov 18, 2018 · 7 comments · Fixed by #8009
Closed
5 of 6 tasks

DjangoModelPermissions does not respect Django can_read_model permissoin #6324

paultiplady opened this issue Nov 18, 2018 · 7 comments · Fixed by #8009
Labels

Comments

@paultiplady
Copy link

Checklist

  • I have verified that that issue exists against the master branch of Django REST framework.
  • I have searched for similar issues in both open and closed tickets and cannot find a duplicate.
  • This is not a usage question. (Those should be directed to the discussion group instead.)
  • This cannot be dealt with as a third party library. (We prefer new functionality to be in the form of third party libraries where possible.)
  • I have reduced the issue to the simplest possible case.
  • I have included a failing test as a pull request. (If you are unable to do so we can still accept the issue.)

Steps to reproduce

Use DjangoModelPermissions on a ViewSet, and access with a user that does not have can_view_<model> permisson.

Expected behavior

The user should not be able to view the model, as they don't have the required permission.

Actual behavior

All authenticated users are granted read-only permission.

@paultiplady
Copy link
Author

Pre-Django 2.1 there wasn't a built-in "read-only" permission. The framework chooses "fail-open" instead of "fail-close" here, which isn't the default that I'd expect; however now that there is an explicit can_read_model permission, I think it's clear that the DjangoModelPermissions model should respect it.

This would be a breaking change, since any code that's depending on the default read-only behaviour would break. Is that desirable?

The fix itself is trivial.

@paultiplady
Copy link
Author

Breaking back-compat might not be desirable; if so would it be worth adding a subclass that does respect the permission? Something like this would be an option:

class DjangoModelPermissionsStrict(DjangoModelPermissions):
    perms_map = {
        'GET': ['%(app_label)s.view_%(model_name)s'],
        'OPTIONS': [],
        'HEAD': [],
        'POST': ['%(app_label)s.add_%(model_name)s'],
        'PUT': ['%(app_label)s.change_%(model_name)s'],
        'PATCH': ['%(app_label)s.change_%(model_name)s'],
        'DELETE': ['%(app_label)s.delete_%(model_name)s'],
    }

@nemesifier
Copy link
Contributor

Hi everyone, there's a patch which adds support for view permission and is backward compatible: #8009.

@kxbin
Copy link

kxbin commented Sep 3, 2021

This is great, I hope this PR can be merged.

@stale
Copy link

stale bot commented Apr 24, 2022

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@stale stale bot added stale and removed stale labels Apr 24, 2022
@dfrankow
Copy link

Not stale?

@stale
Copy link

stale bot commented Jul 12, 2022

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@stale stale bot added the stale label Jul 12, 2022
@auvipy auvipy added Bug and removed stale labels Dec 15, 2022
ManishShah120 added a commit to ManishShah120/django-rest-framework that referenced this issue Jan 12, 2023
auvipy pushed a commit that referenced this issue Jan 13, 2023
)

* Fix Respect `can_read_model` permission in DjangoModelPermissions

FIXES: #6324

* Updated documentation and simplified code
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
5 participants