Actually, I don't use ldap groups permission really, I have just configured my settings in which AUTH_LDAP_GROUP_SEARCH looks for a posixGroup Type (it is what I use for now, but in the future, it would be logical there will have GroupOfName and other types).
My aim is to use django-auth-ldap only as authentication, because we won't be able to know which groups will be implemented and which Django group will be applied to the LDAP group. I tried to check in django-auth-ldap source code how groups are handled/retrieved, it seems relly complicated (I don't know How should I implement the LDAPBackend and use/override the related method in order to use the LDAP admin to retrieve all the groups and populate them into the Django ORM) For now, the solution I got is to directly use python-ldap library to execute a search request in wich I specify the node I want to look at to retrieve them recursively, and finally, I succeed in populate them) For the links between Django groups and LDAP groups, I have no choice to do this, so I thought I should have to implement a django model (which aim, like other models, is to store stuff in ORM) which could have a OneToManyField in order to link several LDAP groups to my Django groups predefined in my app When you say "If you have ldap subgroups I would flatten them into the smallest denominator and make equivalent auth-groups." I am not sure to understand what it really means and how to implement this, thanks to django-auth-ldap? Or as I already done with python-ldap?? I don't think I could chosse a naming convention if, in advance, it is not possible to me to know which groups will be retrieved, right? Le vendredi 7 septembre 2018 01:57:27 UTC+2, Mike Dewhirst a écrit : > > On 7/09/2018 12:49 AM, Benjamin SOULAS wrote: > > Hi Mike ! > > > > The problem is our app have to be able to retrieve a Customer LDAP > > server. So we won't be able to know groups will be into the LDAP server. > > > > To be concise, when we'll set up the app, we'll have to retrieve the > > LDAP groups, insert them in django ORM, then make the link (with a > > table, so a model) between LDAP groups extracted and our App groups > > Are you using django-auth with auth-groups and auth-group-permissions? > > If it was me, I'd set up all the ldap groups as Django auth-groups and > preset their permissions. Then all the login backend has to do is check > that a user's ldap groups haven't changed. If they have changed then I > would have to adjust the auth-groups accordingly. > > If you have ldap subgroups I would flatten them into the smallest > denominator and make equivalent auth-groups. > > If you choose a strategic naming convention you could work it out on the > fly without needing a mapping table between ldap groups/sub-groups and > Django auth-groups. > > > > > > The App permissions will follow the same principle, stored in the > > Django ORM (which is the regular case) and thanks to the app > > (something django admin-like) we will link the permissions to the App > > groups > > > > I don't know how clear I am ... > > > > Kind regards > > > > Benjamin > > > > Le mercredi 5 septembre 2018 23:51:49 UTC+2, Mike Dewhirst a écrit : > > > > On 5/09/2018 11:25 PM, Benjamin SOULAS wrote: > > > Hi everyone, > > > > > > I m not expert at all in Django so it can be a silly question but > I > > > take the risk: > > > > I'm an expert in nothing! > > > > What about simplifying things by making your groups have smaller > > sets of > > permisssions and putting users into multiple groups to suit their > > roles. > > > > > > > > > > I have to implement *LDAP server* (which work perfectly with > > > *django-auth-ldap*, but my question is not related to this > > library). I > > > was wondering what happens if groups possesses subgroups? Even > > if it > > > is not handled in the lib, I assume I can override a recursive > > > mechanism in order to populate the subgroup in the *auth_group* > > table. > > > > > > BUT my problem is "*How can link subgroups to parent groups*" ? > > > Because through */admin* page, If you create a group, you can only > > > define its permission and nothing else (which make sens if the > > aim is > > > to have One level group handling), but if I want to implement > > > subgroups, how do you suggest to do it? I found the module > > django MPTT > > > but does it corresponds to the need? Bur because I already use > > DRF + > > > Django + Django-auth-LDAP, does its implementation worth it? > > > > > > I though it was possible, thanks to *custom models* which could > > have > > > as fields *parent-group* and *subgroup* (and maybe more, still > > > thinking about it). Once the model is implemented, should I link > my > > > *overriden django-auth-ldap code* to map this Django model in > > order to > > > make the links? Or should I think differently? > > > > > > Just to be more precise, in my app I will have permissions and > > groups > > > defined, the aim is, programmatically or through admin interface > > make > > > also the links between the LDAP groups and my app groups (LDAP > > server > > > could have every possible trees) > > > > > > I don't know if it is clear enough, if not, do not hesitate to > > ask me > > > questions, I really need help actually > > > > > > Kind regards, > > > > > > Benjamin. > > > -- > > > You received this message because you are subscribed to the Google > > > Groups "Django users" group. > > > To unsubscribe from this group and stop receiving emails from > > it, send > > > an email to [email protected] <javascript:> > > > <mailto:[email protected] <javascript:> > <javascript:>>. > > > To post to this group, send email to [email protected] > > <javascript:> > > > <mailto:[email protected] <javascript:>>. > > > Visit this group at https://groups.google.com/group/django-users > > <https://groups.google.com/group/django-users>. > > > To view this discussion on the web visit > > > > > > https://groups.google.com/d/msgid/django-users/0c3fbcde-5959-4d48-b9eb-75b94a6ff350%40googlegroups.com > > > < > https://groups.google.com/d/msgid/django-users/0c3fbcde-5959-4d48-b9eb-75b94a6ff350%40googlegroups.com> > > > > > > > > > < > https://groups.google.com/d/msgid/django-users/0c3fbcde-5959-4d48-b9eb-75b94a6ff350%40googlegroups.com?utm_medium=email&utm_source=footer > > > < > https://groups.google.com/d/msgid/django-users/0c3fbcde-5959-4d48-b9eb-75b94a6ff350%40googlegroups.com?utm_medium=email&utm_source=footer>>. > > > > > > > For more options, visit https://groups.google.com/d/optout > > <https://groups.google.com/d/optout>. > > > > -- > > You received this message because you are subscribed to the Google > > Groups "Django users" group. > > To unsubscribe from this group and stop receiving emails from it, send > > an email to [email protected] <javascript:> > > <mailto:[email protected] <javascript:>>. > > To post to this group, send email to [email protected] > <javascript:> > > <mailto:[email protected] <javascript:>>. > > Visit this group at https://groups.google.com/group/django-users. > > To view this discussion on the web visit > > > https://groups.google.com/d/msgid/django-users/c3f81532-95c8-4152-a36e-97eeb68ccb22%40googlegroups.com > > > < > https://groups.google.com/d/msgid/django-users/c3f81532-95c8-4152-a36e-97eeb68ccb22%40googlegroups.com?utm_medium=email&utm_source=footer>. > > > > For more options, visit https://groups.google.com/d/optout. > > -- You received this message because you are subscribed to the Google Groups "Django users" 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]. Visit this group at https://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/742ac678-8359-4189-8b67-fa420ff01f0f%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
