Skip to content

Missing permission checks in RelatedMixin views #496

Closed
@lcary

Description

@lcary

No object level or model level permissions appear to be checked for related models in RelatedMixin views.

Expected behavior: The related fields should be empty in a response object if the user doesn't have view permission to the related field. Alternatively, if a response must render the related object, a permissions error should be raised.

Observed behavior: Currently, if the user has permission for a model but not related models (e.g. via a foreign key relation), they are still able to view the related object if a RelatedMixin view's serializer has a ResourceRelatedField. This seems to merit at least some documentation warning users about the potential for leaking data, but preferably this issue could be fixed by enabling permissions checking.

Reproducing the issue requires a project that checks that a user has read (or "view") permissions for models they try to access (e.g. using extended versions of DjangoObjectPermissions and DjangoModelPermissions classes mentioned in the django-rest-framework permissions documentation). In such a project, for any RelatedMixin view that uses a serializer with a ResourceRelatedField, grant the user permission to the serializer's model object, but do not grant the user access to the related model. If the user requests the object, they will still be able to access the related field. I'm happy to add a test case for this issue.

Perhaps object level or even model level permissions checking is out of scope for the django-rest-framework-json-api project, but it seems like both should be supported. After all, django-rest-framework supports and advertises both via the DjangoObjectPermissions and DjangoModelPermissions classes. In a project I'm working on, we use django-guardian with a similar class to check object-level permissions. Perhaps I can override RelatedMixin.get_related_instance() in the meantime as a stopgap solution, but a solution via configuration flag or a default in this library would be preferable.

Best,
Luc

Metadata

Metadata

Assignees

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions