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 django-users...@googlegroups.com <javascript:>
> <mailto:django-users+unsubscr...@googlegroups.com <javascript:>>.
> To post to this group, send email to django...@googlegroups.com
<javascript:>
> <mailto:django...@googlegroups.com <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 django-users+unsubscr...@googlegroups.com
<mailto:django-users+unsubscr...@googlegroups.com>.
To post to this group, send email to django-users@googlegroups.com
<mailto:django-users@googlegroups.com>.
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 django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
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/7b456cc0-62e2-b1e3-e410-b2c1b4a695a6%40dewhirst.com.au.
For more options, visit https://groups.google.com/d/optout.
