the design of django group permission should be optimized in django.contrib.auth.ModelBackend

[程SN]

Hi everybody,

the information is not enough for my company in django.contrib.auth.models.Usre and django.contrib.auth.models.Group. So I custom User and Team model.

the auth User can be changed in the django settings by AUTH_USER_MODEL. But the Group cannot.

 

Further, There are many group permissions problem presented when I use django permissions. 

Firstly, I cannot use django.contrib.auth.ModelBackend directly.

in django.contrib.auth.ModelBackend,  Django currently bind group permissions with  django.contrib.auth.models.Group

    def _get_group_permissions(self, user_obj):
        user_groups_field = get_user_model()._meta.get_field('groups')
        user_groups_query = 'group__%s' % user_groups_field.related_query_name()
        return Permission.objects.filter(**{user_groups_query: user_obj})

Why the group cannot be changed in the settings like AUTH_USER_MODEL ?  Can Djano support AUTH_GROUP_MODEL in the further release?

So I have to custom backend that extend django.contrib.auth.ModelBackend and modify group to my team.

But I find the other problem  in my further developing.  The bad design  limit the other app design.

Many app about django permission , only  support group permission based on django.contrib.auth.models.Group, like django-guardian

It's too bad.  Please support AUTH_GROUP_MODEL

 

---

Regards,

damoncheng

[Adam Johnson]

Hi damoncheng,

Previous to swappable User model, the best practice was to define a secondary model with OneToOneField to User for storing auxiliary information. You could do this for Group to solve your use case now.

As for the feature request, I wouldn't be against it, though I'm not really in favour of it either. I'd estimate it to be a medium-sized Django ticket. Would you be able to make the contribution? Or are you just requesting that "someone" do it? Features don't tend to get added to Django except by motivated individuals who'd like to see them there :)

Thanks,

Adam

--
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-develop...@googlegroups.com.
To post to this group, send email to django-d...@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CABeySRubsPtBiNmH1tt8hnZTPvTz-ZqXLEZ-azBK-jodV98-HQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

--

Adam

[snhe...@gmail.com]

Hi Adam,

After you reply, I make team OneToOneField to Group.  Though it can sovle the basic problem.  it have some problem in my scene. 

My project is a cloud item.  it use SCIM to manage user and team identities in cloud.  it transfer resource from sender to many receiver. 

Before I use OneToOneField,   I only transfer user and team from sender to receiver.   It spend 2 hour.

After  I use OneToOneField.  I  need transfer user and team from sender to receiver, then create group and make team OneToOneField to Group in the receiver. It spend 6 hour.

it degrade the transform perform. So I decide to accept your suggestion and contribution to django , support AUTH_GROUP_MODEL.

I am first to contribute to django. I am getting familar with django ticket now.

在 2018年9月2日星期日 UTC+8上午4:41:11，Adam Johnson写道：

[Tim Graham]

I'm not sure. Swappable models still have some rough edges. In particular, switching to a swappable model after beginning a project is difficult and undocumented (https://code.djangoproject.com/ticket/25313). To overcome this, the documentation recommends starting with a custom user model (https://code.djangoproject.com/ticket/24370) -- I'm not sure if we would want to make the same recommendation for the group model as I suspect it wouldn't be swapped as often.

I see you created a ticket to add an AUTH_GROUP_MODEL setting.

https://code.djangoproject.com/ticket/29748

[charettes]

Something I would add is that while some third-party apps leverage swappable models it is not clear how relationships between swappable models should be dealt with.

This is something we'd have to figure out if `auth.Group` is made swappable as the default model user model would depend on it.

Simon

[snhe...@gmail.com]

Hi Tim:

      The english is not my first language.  so please excuse me that my some statement maybe isn't accurate. But I will do my best to make my expression clear.

      

       Maybe the default group model can satisfy the most scene by the project developer complicated design. But  it is not mean that it wouldn't be swapped as often. Now it is that it can't be swapped all the time.  the design should give choose to developer.  I suspect that if the project developer can custom their group model. they will often choose the 
easier and basic way. 

Regards,

damoncheng

在 2018年9月10日星期一 UTC+8下午11:12:52，Tim Graham写道：

[snhe...@gmail.com]

It's a headache thing that replace `groups in auth.models.PermissionsMixin` to `auth.Group`. because of the backward compatibility. I can not adjust some code position. I have been written some patches. But they are not enough well. I am working on it.

在 2018年9月11日星期二 UTC+8上午1:49:33，charettes写道：

[John D'Ambrosio]

I believe this change is merited and I would be happy to help if others are interested in working this.  I have actually monkey-patched it a few times now for two reasons:

a) I want more data fields on the group itself, or

b) I want to implement nested groups

MPTT's docs suggest one approach which is gross (no offense) because it creates migrations in a contrib app!

https://django-mptt.readthedocs.io/en/latest/models.html?highlight=group#registration-of-existing-models

The nested group concept has the added concern of the PermissionsMixin leveraging a few helper functions which are defined outside of the class and not easily swappable themselves.  Maybe if we proceed on this we tackle it in two phases.  In the first, we can align all of the pieces to make it more easily swappable.  In the second, we can introduce the swap.  We definitely will want to avoid some of the pitfalls of AbstractUser and UserManager where one is unable to import varying degrees of scaffolding without invoking the concrete pieces we are not using.

I agree with Tim that the swappable model approach is less than ideal and not well-documented for transitions, but maybe those of us who've done it can submit some detailed guides with some concrete steps of how to swap out the table namespaces and retire the old models retroactively, as well as the usual (maybe even stronger) encouragement to pull in the models to your core app up-front?  Could even have startproject do it for you in the future... maybe recommend an "accounts" app or something?

Anyway, happy to help.  Please let me know if there is interest in proceeding.

[Tom Clark]

I'd be very interested in this. But it seems like one helluva lot of work, to enable people to customise their Group model.

I think in general, there are two reasons why one want to use a swappable model in this case:

- To create nested relationships with e.g. mptt.

- To add a field or two onto the model.

Couldn't these two use cases be better solved by simply updating the existing Group model:

- Add a `meta` JSONField (now generically included in Django, not just postgres anymore) so people can hang extra metadata in there if required

- Add mptt right in there so that groups can be added to other groups?

We could carve code out from django-groups-manager to achive this straightforwardly, but it introduces mptt as a dependency of a contrib app.

What do you think, @John? Is this likely to be accepted into Django?

[Tobias Bengfort]

I also have experience with the limitations of the default permission
system. But I don't think it is necessarily a problem. There are two
options to deal with it:

- Django could add small bits of flexibility, e.g. make the group model
swappable. This adds complexity that needs to be accounted for in all
relevant libraries, e.g. django-guardian.

- Django could make it easier to write custom authentication backends.
This gives complete control to application developers, at the cost of no
longer being compatible with many libraries, e.g. django-guardian.

I personally lean to the second options as I believe it allows to have
cleaner application designs. But it think it is hard to get the right
balance.

tobias

>>> __%s' % user_groups_field.related_query_name()

>>> return Permission.objects.filter(**{user_groups_query: user_obj})
>>>
>>> Why the group cannot be changed in the settings like AUTH_USER_MODEL ?
>>> Can Djano support AUTH_GROUP_MODEL in the further release?
>>>
>>> So I have to custom backend that extend django.contrib.auth.ModelBackend
>>> and modify group to my team.
>>>
>>> But I find the other problem in my further developing. The bad design
>>> limit the other app design.
>>>
>>> Many app about django permission , only support group permission based
>>> on django.contrib.auth.models.Group, like django-guardian
>>>
>>> It's too bad. Please support AUTH_GROUP_MODEL
>>>

>>> ------------------------------
>>> Regards,
>>>
>>> damoncheng
>>>
>>
>

[LBris]

Hi everyone.

What is the state of this discussion and its attached ticket ?

[Adam Johnson]

Exactly as you see, nothing is done in secret.

On Fri, 24 Jan 2020 at 08:44, LBris <laurent...@gmail.com> wrote:

Hi everyone.

What is the state of this discussion and its attached ticket ?

--

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-develop...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/47517107-c5d2-4986-8845-087cba05e340%40googlegroups.com.

--

Adam

[Bendegúz Csirmaz]

Hi!

I would be happy to make a contribution if a decision can be reached.

I'm in favor of making the Group model swappable with the AUTH_GROUP_MODEL setting, similar to the User model.

The ticket was marked as Someday/Maybe, I'm not sure why.

The customization of the Group model is necessary in any bigger project, and defining a secondary model doesn't always cut it (e.g. when nesting the Group model).

AUTH_GROUP_MODEL is consistent with the User model and addresses all customization concerns.

Yes, it's hard to swap the User model in production, and it will be hard to swap the Group model.

It's still better than hacking around Django (see: https://stackoverflow.com/questions/2181039/how-do-i-extend-the-django-group-model).

I opened a PR to add this, it addresses the basic functionality.

Let me know!