#32255: User.has_perm should forward **kwargs to allow more flexibility in
authentication backends
-------------------------------------+-------------------------------------
Reporter: Matteo Parrucci | Owner: nobody
Type: New feature | Status: new
Component: contrib.auth | Version: 3.1
Severity: Normal | Resolution:
Keywords: auth, | Triage Stage:
django.contrib.auth, | Unreviewed
authentication, request, |
has_perm, has_perms, sites, |
django.contrib.sites |
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Description changed by Matteo Parrucci:
Old description:
> **The situation**
> I would like to check user permission based on the django.contrib.sites
> I'm in. To get the active site, django.contrib.sites needs the request so
> he can match the hostname. I'm using django-rules at the moment but It's
> quite generic.
>
> **The Problem**
> Not having the request in has_perm/has_perms I cannot check permissions
> based on the currently active site
> The "call stack" detail is here: https://github.com/dfunckt/django-
> rules/issues/130
>
> **A possible solution**
> Adding *args and ^^*^^*kwargs to has_perm and has_perms signatures would
> allow greater flexibility for the custom authentication backends leaving
> intact what we have now. In my case, for example, I could check
> permission in my django-rules predicates having the the request passed in
> and check if I have rights for the current site, but I think my case is
> quite limited and all new authentication backends would benefit from this
> change.
New description:
**The situation**
I would like to check user permission based on the django.contrib.sites
I'm in. To get the active site, django.contrib.sites needs the request so
he can match the hostname. I'm using django-rules at the moment but It's
quite generic.
**The Problem**
Not having the request in has_perm/has_perms I cannot check permissions
based on the currently active site
The "call stack" detail is here: https://github.com/dfunckt/django-
rules/issues/130
**A possible solution**
Adding ^^*^^*kwargs to has_perm and has_perms signatures would allow
greater flexibility for the custom authentication backends leaving intact
what we have now. In my case, for example, I could check permission in my
django-rules predicates having the the request passed in and check if I
have rights for the current site, but I think my case is quite limited and
all new authentication backends would benefit from this change.
--
--
Ticket URL: <https://code.djangoproject.com/ticket/32255#comment:1>
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 view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/064.342a3d7b3b6f75bbb00d324c513bd8c0%40djangoproject.com.