rpkilby / django-rest-framework-guardian Goto Github PK

Hi, thanks for your work on this.

I just ran into the following error while trying to install via pipenv, using python 3.6.6

It looks like a checksum failure on the package, or a dependency. Let me know if you can reproduce it please!

$ pipenv install djangorestframework-guardian
Courtesy Notice: Pipenv found itself running within a virtual environment, so it will automatically use that environment, instead of creating its own for any project.
Installing djangorestframework-guardian…
Requirement already satisfied: djangorestframework-guardian in /home/jules/.local/share/virtualenvs/django-poc-mXC5fPn1/lib/python3.6/site-packages (0.3.0)
Requirement already satisfied: djangorestframework in /home/jules/.local/share/virtualenvs/django-poc-mXC5fPn1/lib/python3.6/site-packages (from djangorestframework-guardian) (3.10.3)
Requirement already satisfied: django in /home/jules/.local/share/virtualenvs/django-poc-mXC5fPn1/lib/python3.6/site-packages (from djangorestframework-guardian) (2.2.6)
Requirement already satisfied: django-guardian in /home/jules/.local/share/virtualenvs/django-poc-mXC5fPn1/lib/python3.6/site-packages (from djangorestframework-guardian) (2.1.0)
Requirement already satisfied: pytz in /home/jules/.local/share/virtualenvs/django-poc-mXC5fPn1/lib/python3.6/site-packages (from django->djangorestframework-guardian) (2018.4)
Requirement already satisfied: sqlparse in /home/jules/.local/share/virtualenvs/django-poc-mXC5fPn1/lib/python3.6/site-packages (from django->djangorestframework-guardian) (0.3.0)

Adding djangorestframework-guardian to Pipfile's [packages]…
Pipfile.lock not found, creating…
Locking [dev-packages] dependencies…
Locking [packages] dependencies…
", line 341, in open_local_or_remote_file
    response = session.get(url, headers=headers, stream=True)
  File "/usr/lib/python3/dist-packages/pipenv/vendor/pip9/_vendor/requests/sessions.py", line 488, in get
    return self.request('GET', url, **kwargs)
  File "/usr/lib/python3/dist-packages/pipenv/vendor/pip9/download.py", line 386, in request
    return super(PipSession, self).request(method, url, *args, **kwargs)
  File "/usr/lib/python3/dist-packages/pipenv/vendor/pip9/_vendor/requests/sessions.py", line 475, in request
    resp = self.send(prep, **send_kwargs)
  File "/usr/lib/python3/dist-packages/pipenv/vendor/pip9/_vendor/requests/sessions.py", line 596, in send
    r = adapter.send(request, **kwargs)
  File "/usr/lib/python3/dist-packages/pipenv/vendor/pip9/_vendor/cachecontrol/adapter.py", line 37, in send
    cached_response = self.controller.cached_request(request)
  File "/usr/lib/python3/dist-packages/pipenv/vendor/pip9/_vendor/cachecontrol/controller.py", line 111, in cached_request
    resp = self.serializer.loads(request, cache_data)
  File "/usr/lib/python3/dist-packages/pipenv/vendor/pip9/_vendor/cachecontrol/serialize.py", line 114, in loads
    return getattr(self, "_loads_v{0}".format(ver))(request, data)
  File "/usr/lib/python3/dist-packages/pipenv/vendor/pip9/_vendor/cachecontrol/serialize.py", line 176, in _loads_v2
    cached = json.loads(zlib.decompress(data).decode("utf8"))
zlib.error: Error -3 while decompressing data: incorrect data check''

@rpkilby Since the last commit/activity on this repo is nearly 2 years old, is this project no longer supported?

I would volunteer to help with basic maintenance (make new releases, making sure the package is tested and works on latest Django and Python versions) if you would like help on the project.

I'm having a bit of trouble following the documentation. I have a question regarding how to deal with the permissions using django-rest-framework-guardian. I followed the example in which I add the mixing and change the serializer filter backend and permissions class as stated.

My problem is, once I enable the backend and class for filter and permissions I don't have permissions for listing an endpoint unless I assign view permission explicitely under django admin. Do you need to assign to users all the default django permissions (add_model, view_model, etc) to a user in order to allow django guardian to deal with the object permissions?

It's a bit of a confusing question but I'm unsure from the documentation how the permissions are dealt with from a view perspective and an object perspective.

def get_permissions_map(self, created):       
        current_user = self.context['request'].user
        print(current_user)
        return {
            'view_event': [current_user],
        }

when I add current_user, in the list I get the following error: 'Permission matching query does not exist'

I saw this when installing from a source dist. Perhaps something is not set up correctly with the source distribution?

Relates to #9

This is a duplicate of: encode/django-rest-framework#5896

When using guardian to filter by object permission I noticed the DjangoObjectPermissionsFilter class uses the shortcut function get_objects_for_user to get the object queryset, however in doing so, it's building the permission parameter in the form of app_label.view_model. When used in this manner guardian is performing a database call each time the function is called to determine the proper content type for which the permission is valid. Instead it should be using the form of view_model and guardian is smart to figure out where that permission belongs from the queryset parameter and under the hood uses django's contenttype manager which caches the result so further calls do not query the database.

For the time being I'm working around this issue by overriding this class and setting perm_format = 'view_%(model_name)s' instead, so when passed to guardian it's in the form of 'view_model' only.

Hi!

I just found out that DjangoObjectPermissionsFilter is deprecated in DRF 3.9 and going to be replaced with this module (the code is identical to the one in DRF right now, as far as I can see).

For us, the preferred behaviour is that some users get global model permissions with the intended semantics that they can view (change) all model objects and the ones who are only allowed to view (change) certain model objects get object permissions for the specific model.

Which means we use accept_global_perms=True on all our views. ;)

Currently there's no abstraction for this, so I have to completely copy + paste the whole DjangoObjectPermissionsFilter class to get the intended behaviour:

from rest_framework.filters import BaseFilterBackend

class GlobalObjectPermissionsFilter(BaseFilterBackend):
    """A filter backend that limits results to those where the requesting user
    has read object level permissions.

    Contrary to the assumptions in DjangoObjectPermissionsFilter we
    assume that global model permissions mean that the user can access
    *all* objects (we use accept_global_perms on all views.)

    This means we have to copy / paste DjangoObjectPermissionsFilter
    here, since there's no abstraction to provide for that case.

    """
    def __init__(self):
        assert guardian, 'Using GlobalObjectPermissionsFilter, but django-guardian is not installed'

    perm_format = '%(app_label)s.view_%(model_name)s'

    def filter_queryset(self, request, queryset, view):
        # We want to defer this import until run-time, rather than import-time.
        # See https://github.com/encode/django-rest-framework/issues/4608
        # (Also see #1624 for why we need to make this import explicitly)
        from guardian.shortcuts import get_objects_for_user

        user = request.user
        model_cls = queryset.model
        kwargs = {
            'app_label': model_cls._meta.app_label,
            'model_name': model_cls._meta.model_name
        }
        permission = self.perm_format % kwargs
        return get_objects_for_user(user, permission, queryset,
                                    accept_global_perms=True)

Not sure what would be the best way here, maybe a get_objects_for_user_kwargs class property would simplify things.

The README says:

For more information on adding 'view' permissions for models, see the relevant section of the django-guardian documentation, and this blogpost.

But if you view the latest django-guardian docs, you'll see a note that Django 2.1+ already includes view permissions now.

Note that the latest django-guardian docs are not published to readthedocs yet due to django-guardian/django-guardian#618. Update: the latest docs have now been published.

The README should should probably be tweaked to show how to use the normal Django view permissions, or simply show how no extra code is needed for the user.

Say you have 2 models, where model A is related to model B by a ForeignKey and that the authenticated user is only authorized to see a subset of the objects of model B, in the browsable API that user can still select from the full list of objects of model B instead of just the subset they're allowed to see.

I suppose this has to do with the automatically generated Field for the relationship inside the Serializer of model A. So how could I add an object permission filter to that?

@rpkilby If a user wants to cache dependencies for offline install and use source downloads, this fails for djangorestframework-guardian

$ pip download --no-binary=:all: djangorestframework-guardian
Collecting djangorestframework-guardian
  ERROR: Could not find a version that satisfies the requirement djangorestframework-guardian (from versions: none)
ERROR: No matching distribution found for djangorestframework-guardian

You can see that only the .whl is uploaded here: https://pypi.org/project/djangorestframework-guardian/0.3.0/#files

During normal installs, pip will default to using .whl, so this will not slow down the normal use case, but will enable users to pull down source distributions if they wish.

Could .tar.gz source archive also be added for 0.3.0 (and future versions)?

I think the command you can use to generate it is:

$ python setup.py sdist --formats=gztar