New permissions package: DRY Rest Permissions: allows definition of permissions for individual API actions and returning of results through serializers

[David Kaplan]

We just open sourced our permission package that is built on top of Django Rest Framework.

https://github.com/Helioscene/dry-rest-permissions

It allows developers to easily define permissions for individual API actions. It has support for all default actions (create, list, retrieve, destroy, update, partial_update) and custom actions. It is meant for apps that define their permissions implicitly based on existing data and relationships in their database. For example I want all owners of a project to be able to update it, but only want admins of a project to be able to destroy it.

It also supports returning all evaluated permissions to a client app through a serializer. So, for example, if you retrieve a project for a user, it can also return whether the user has the ability to update and destroy the project so that the client app can display options accordingly. DRY!

Lastly, it has support for filtering down list actions (default and custom list actions) so that users can only retrieve what they have permission to see.

[Jean Ventura]

I just found your project while looking for an alternative to django-guardian and I like what I'm reading. Thing is, I don't know if it's the right fit for the project I'm currently designing. I can't wrap my head around how to use it for my own purpose, is there a tutorial or guide I can use? Should I have knowledge of an specific topic before comprehending this library?

Would really appreciate any help on the matter, seems like this is what this project needs.

[David Kaplan]

Hi Jean,

Can you tell me a bit about what you need, and maybe I can give you a bit of an in depth answer tailored to what you are looking for.

We created this package because we found that our project had many complex models and relationships between them (about 20 models and about 30 relationships back to the user model). Using something like django guardian would have forced us to write triggers everywhere that updated users permissions that were explicitly stored in the database. We created dry-rest-permissions so that we could define permissions implicitly using the relationships that already exist back to the user.

The power is that you can define both broad permissions and specific ones down to a single row and action.

--
You received this message because you are subscribed to a topic in the Google Groups "Django REST framework" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/django-rest-framework/MzHuv3_zWHc/unsubscribe.
To unsubscribe from this group and all its topics, send an email to django-rest-fram...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Jean Ventura]

Hello Mr. Kaplan,

Thanks for taking the time to answer me.

" you can define both broad permissions and specific ones down to a single row and action."

This is what caught my attention.

The application I'm working on has a lot of models and relationships that trace back to a person model, which in turn is related to the django user model.

One use case I can give: a person from the model mentioned before, is part of a branch, which in turn is part of a company. I need to be able to control what rows from other related models said person can see, based on its type (and some other attributes) and to what organization it belongs to.

I'm in the early stages of designing the database schema and I'm open to changes in order to achieve something close to what I described before.

Hope this give you an idea of what I want to do. If you need more details, please feel free to ask.

[David Kaplan]

This sounds like a perfect fit for dry-rest-permissions.

So it sounds like your user permissions for objects will be based on the branch and company a user is related to (belongs to).

If that is correct I am assuming that the objects you want to permission are also somehow related to branches and/or companies.

If that is the case you could do something like this:

Let's say you have objectx and you want users who belong to objectx's company to be able to view it.

You can add DRYRestPermissions to the permissions attribute on objectx's view like so:

class ObjectXViewset(viewsets.ModelViewSet):

    permission_classes = (DRYPermissions, )

This will tell the system that ObjectX is governed by DRYRestPermissions. Next you can define the retrieve (view) permission on the model for ObjectX.

class ObjectX(models.Model):

    company = models.ForeignKey(Company)

    @staticmethod

    def has_retrieve_permission(request):

        """We will open up table level retrieve permissions because we only care about row level in this example"""

        return True

    def has_object_retrieve_permission(self, request):

        """make sure the requesting user is part of the company associated to ObjectX"""

        return self.company == request.user.branch.company

[Jean Ventura]

Hmmm, I see... My relationships are all in M2M entities, but I think I get the idea. I'll experiment and report back with my results.

Thanks for the help!

To unsubscribe from this group and all its topics, send an email to django-rest-framework+unsub...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to a topic in the Google Groups "Django REST framework" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/django-rest-framework/MzHuv3_zWHc/unsubscribe.

To unsubscribe from this group and all its topics, send an email to django-rest-framework+unsub...@googlegroups.com.

[Jean Ventura]

Sorry about the long time to get back to you, I wasn't able to test this until now but, you are completely right Mr. Kaplan, DRY-REST-permnissions is a perfect solution for our problem (I did have to use 'read' instead of 'retrieve' for the methods).

Thank you for the assistance, and if there's any help me or my team can provide with issues, documentation or testing, we'll be happy to pitch in. Is there a mailing list or channel? or is everything handled via GitHub?

On Thursday, October 29, 2015 at 10:08:42 PM UTC-4, David Kaplan wrote:

To unsubscribe from this group and all its topics, send an email to django-rest-framework+unsub...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to a topic in the Google Groups "Django REST framework" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/django-rest-framework/MzHuv3_zWHc/unsubscribe.

To unsubscribe from this group and all its topics, send an email to django-rest-framework+unsub...@googlegroups.com.

[David Kaplan]

Hi Jean,

Right now everything is handled via github.

I would love help, especially with the documentation. If you see anything unclear or that needs more explaining please let me know or even better fix it and send me a PR.

Also I would love to hear if you have any recommendations for new features.

To unsubscribe from this group and all its topics, send an email to django-rest-fram...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to a topic in the Google Groups "Django REST framework" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/django-rest-framework/MzHuv3_zWHc/unsubscribe.

To unsubscribe from this group and all its topics, send an email to django-rest-fram...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to a topic in the Google Groups "Django REST framework" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/django-rest-framework/MzHuv3_zWHc/unsubscribe.

To unsubscribe from this group and all its topics, send an email to django-rest-fram...@googlegroups.com.