#27950: Permission classes for Class Based Views
-------------------------------------+-------------------------------------
Reporter: Piotr | Owner: nobody
Szpetkowski |
Type: New | Status: new
feature |
Component: Generic | Version: master
views | Keywords: permissions, view,
Severity: Normal | cbv
Triage Stage: | Has patch: 0
Unreviewed |
Needs documentation: 0 | Needs tests: 0
Patch needs improvement: 0 | Easy pickings: 0
UI/UX: 0 |
-------------------------------------+-------------------------------------
I would like to propose to add support for permission classes for generic
views (CBV) to make it simpler to add custom requirements per specific
view. Syntax could be based on what is done inside DRF at the moment, so
setting it up at the view level it would be very simple and convenient:
{{{#!python
class CustomView(View):
permission_classes = (IsAuthenticated, IsReadOnly)
}}}
That would evaluate to `IsAuthenticated AND IsReadOnly`. I'm not entirely
sure however what syntax should support `IsAuthenticated OR IsReadOnly`.
One of possible ways is to write one permission class for both conditions
called `IsAuthenticatedOrReadOnly` (it's the way DRF is doing it), however
it does not sound like the best solution. I suppose that a proper (but not
100% pythonic) way to handle such cases would be to override some
operators (e.g. bitwise or - that's what `Q` object does):
{{{#!python
class CustomView(View):
permission_classes = (IsAuthenticated | IsReadOnly,)
}}}
I suppose that it would be nice to be able to provide list for
`permission_classes` as well if anyone would like to do so:
{{{#!python
class CustomView(View):
permission_classes = [IsAuthenticated]
}}}
In case of not meeting requirements of `permission_classes` it might
simply return 403 Forbidden response (with a possibility to provide custom
template and maybe also completely override the behavior method?)
Thanks to OOP custom permission classes might and should be very simple
(just like in DRF):
{{{#!python
class IsAuthenticated(BasePermission):
def has_permission(self, request, view):
return request.user and request.user.is_authenticated
}}}
It's true that similar behavior can be achieved using decorators, however
in my opinion decorator syntax is more complicated than a single class
attribute. Let's keep in mind that simple is better than complex. I'd
gladly start working on it if it turns out to be a good idea. In fact -
I've done something alike I've described in here for one of commercial
projects and it works great.
--
Ticket URL: <https://code.djangoproject.com/ticket/27950>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/060.8797cd4580a93c23a70d8520fbb5ef0c%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.
