Hi Mehmet,
Sorry for the slow reply. I didn't have capacity to return to this last
week.
> Hey Carlton ... What do you say?
Well, my first thought is that I don't see any great consensus for a change
here.
I don't see it as **my** decision to make.
This has been open a while, however, so..
Aymeric,
If one doesn’t have time to read 21 emails, then should also not have time
to judge them.
Regards,
On Fri, Jan 19, 2018 at 2:33 PM Aymeric Augustin <
aymeric.augus...@polytechnique.org> wrote:
> 2018-01-19 17:54 GMT+01:00 Mehmet Dogan :
>
>> I propose throwing out the proposed behavior
2018-01-19 17:54 GMT+01:00 Mehmet Dogan :
> I propose throwing out the proposed behavior as Option B, and see what
> happens.
>
"Make changes and see what happens" doesn't sound like the way Django is
maintained in general.
Unfortunately I don't have enough motivation to go through the 21 emails
Hey Carlton,
I think everybody said what they would. What do you say?
I propose throwing out the proposed behavior as Option B, and see what
happens. Something along these lines:
*class *ModelBackendIgnoreObject(ModelBackend):
*def *get_user_permissions(self, user_obj, obj=*Non
Hey Mehmet,
If a backend relies on PermissionAuthorizationBackend, and another
require the ModelOnlyPermissionAuthorizationBackend
So I think this is the point that confuses me. Why you would use
the user API if you cared about a specific backend?
Using your example of the RolesBackend, e
For the migration, I think most sensible way is to *extend *the current
backend and provide it as an option, until the other is depreciated and
removed. This would act as a global setting in the meantime. But
eventually, I think, we should have just 1 default backend for the sake of
consistency ove
Andrew,
Yes, I think we can safely assume *apps *would be backend agnostic. I was
actually referring to the *backends *themselves, if they use
user.has_perm(...). This might sound counter-intuitive at first but I think
it is possible, and actually I am working on one right now (see my long
answer
On Thursday, January 18, 2018 at 2:55:27 AM UTC+1, Mehmet Dogan wrote:
>
> If that is the way forward, I will volunteer for the code. But, as you
> also point out, there needs to be a *path* out. That I don't know :)
>
Personally I think it is (though I haven't had hours to think about it).
Th
Mehmet,
Can you explain to me what the situation would be that an app could
simply not be backend agnostic?
Given that AUTHENTICATION_BACKENDS is a /user/ configuration, it seems
odd that an app would ever design around specific backends being
installed. I'm not sure I follow your logic on
The "expected behavior" is that *one has permission on an entire table
would also have permission on a row of it*. This seems to be the one thing
that everyone can agree on. And, I am yet to see a person that argues
otherwise. But, it seems, we just need someone or some people to make
that *hard
*d
Andrew,
Thank you for the input. Having options is good. My concern about that is,
it may divide the already small backends population. If a backend relies on
PermissionAuthorizationBackend, and another require the
ModelOnlyPermissionAuthorizationBackend; then one cannot use both.
Guardian, at its
On Wednesday, January 17, 2018 at 7:58:17 PM UTC+1, Carlton Gibson wrote:
>
> Given your comment, would it be along the lines of "Close as "Won't Fix",
> perhaps with a review of the documentation", to point users to subclassing
> ModelBackend if they need the alternate behaviour?
>
My comment
Hi Florian,
I was hoping you'd post. You've been active on the entire (very-long)
history of this issue.
Can I ask for your take?
Given your comment, would it be along the lines of "Close as "Won't Fix",
perhaps with a review of the documentation", to point users to subclassing
ModelBacken
Hi Carlton,
Thanks for the thoughts. I just wanted to share my opinion on your
options.
1. "Won't Fix"
I have yet to find anywhere the original design decisions were
documented. Based on what I can find, it appears that object level
permissions where a bit of an after-though for the i
On Wednesday, January 17, 2018 at 5:48:03 PM UTC+1, Mehmet Dogan wrote:
>
> Florian,
>
> Can you clarify this part, I am not sure what you meant:
>
class MyBackend(ModelBackend):
def has_perm(…, obj=None,…):
if obj: obj = None
return super().has_perm(…)
something along the lines of
Florian,
Can you clarify this part, I am not sure what you meant:
> in the worst case the user would have to change the permission backend
which is easy enough…
On Wed, Jan 17, 2018 at 10:31 AM Florian Apolloner
wrote:
>
>
> On Wednesday, January 17, 2018 at 11:45:05 AM UTC+1, Carlton Gibson w
On Wednesday, January 17, 2018 at 11:45:05 AM UTC+1, Carlton Gibson wrote:
>
> The objection is to this kind of check:
>
> if user.has_perm('foo.change_bar', obj=bar) or
> user.has_perm('foo.change_bar'):
> ...
>
FWIW I would never write code like this. `user.has_perm('
Hi Mehmet,
Due to the BC issues, this is fairly in-depth.
Having looked at the history, here are my initial thoughts.
The initial issue here is this behaviour from `ModelBackend`:
```
user.has_perm('foo.change_bar', obj)
False
user.has_perm('for.change_bar')
True
```
Although the long-sta
I updated my patch:
https://github.com/django/django/pull/9581
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-dev
And I forgot; 3rd advantage:
- The 3 backend methods mentioned above won't have to take an extra
kwarg such as fallback_to_model; thus backward compatible there.
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django its
Seems like I found a better keyword argument than fallback_to_model. For
the following backends setting:
AUTHENTICATION_BACKENDS = (
'django.contrib.auth.backends.ModelBackend',
'guardian.backends.ObjectBackend',
'roles.backends.RoleBackend',
)
And the ways to check:
user.has_pe
Created a pull request: https://github.com/django/django/pull/9581
Mehmet
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to
Based on this patch: the following 3 methods in the custom authorization
backends will have to admit a *fallback_to_model *keyword argument:
*def *has_perm(self, user_obj, perm, obj=None, fallback_to_model=None)
def get_group_permissions(self, user_obj, obj=None, fallback_to_model=None)
def ge
Here is a sample patch:
https://github.com/doganmeh/django/commit/d85cd3a530984ab5e4cb42f93629a64eb0b65b07
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving
And the other:
Here is what I propose in terms of working around the backward
compatibility that seems to have kept it from being solved for so long.
1) define a global setting, say: OBJECT_PERMISSION_FALLBACK_TO_MODEL=False.
This is to help maintain the default behavior (unless the setting i
Here is the text of linked stuff for convenience:
For authorization backends checking object level permissions (like
guardian) usually requires calling the django's default authorization
backend as a fallback to the more general set of permissions:
if user.has_perm('foo.change_bar', obj=bar) or
26 matches
Mail list logo
