Page 1 of 1

LDAP Group Improvements

Posted: 04 Aug 2016, 19:25
by troycarpenter
I would like to see all of the roles exposed via the LDAP group mapping function. In particular, I would like to see the following:

madsonic.disabled: A group that disables access to Madsonic. Just because someone has an LDAP account doesn't mean I want them to have access to the system. If a name is in the group, they are disabled. If a name is not in the group, then enable access for that user. If the group does NOT exist in LDAP, do nothing.

I would also like to see a mutually exclusive group that does the opposite. That is, have a "madsonic.enabled" group, and if the group exists in LDAP, only enable the user if they are in in the group. In case an admin uses both groups, have this one override the other. Maybe provide a warning in the LDAP tab if both groups exist.

With both groups, someone could decide which is easier for them to use. If everyone in LDAP gets access to Madsonic, then the admin can use the madsonic.disabled group to selectively disable. If only a small subset of users in LDAP have access to Madsonic, then the admin can use the madsonic.enabled group instead. Giving both options allows the admin to choose which one will be less work for that admin.

Also, there needs to be a clarification between the documentation and the actual roles:

In Madsonic, there are these:
User is allowed to change cover art and tags
User is allowed to create and edit comments and ratings

In LDAP documentation, you have:
madsonic.cover :: Madsonic cover & comment edit role
madsonic.comment :: Madsonic editor role

It's not too clear in the LDAP which get mapped where. I assume it's the same order listed...but the description for madsonic.cover overlaps with the second one and can be confusing. Perhaps in the LDAP documentation you should mirror the verbage from Madsonic so the mapping is more clear.

Re: LDAP Group Improvements

Posted: 10 Aug 2016, 20:09
by frank2228
I just want to bump this and say that I will be happy to test out anything.

Another idea I had (please let me know if I should create a new Feature Request) is to have the user's Avatar stored in the LDAP directory. After quick google searching I see that there is an attribute called jpegPhoto which can be applied to inetOrgPerson, maybe we can work with that.
StackOverflow post where I saw the jpegPhoto attribute:
http://stackoverflow.com/questions/1339 ... to-in-ldap