Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

User Access mapping using site names in multi-valued attribute instead of a string of site IDs #159

Open
bluikko opened this issue Aug 8, 2017 · 1 comment

Comments

@bluikko
Copy link

bluikko commented Aug 8, 2017

The current method for user read-only/admin access mapping is very difficult to use since it involves translating a site name to a site ID and then making a string from the list of the IDs.

Why not instead: list the name of the site as multi-valued attribute, one site name per attribute instance?

So for example, if LDAP attribute "Url" is used for read-only access mapping and the user should have access to site1.com and site2.com, LDAP would look like:
Url: site1.com
Url: site2.com

With this method, giving/removing access to a user becomes a simple task of adding/removing site names in a multi-valued attribute. And it is very easy in Active Directory environment to list/add/remove site names from multi-valued attributes if choosing to use an attribute that ADUC supports.

@bluikko
Copy link
Author

bluikko commented Mar 31, 2022

I wish this issue would get more attention.
The current Matomo Access Synchronization is difficult to manage because the Site IDs may change on a daily basis for a busy instance - basically meaning the access permissions in LDAP would need to be managed by some system that is aware of the Matomo sites and their IDs.

If it is too big of a change to move to multi-value attributes then please at least consider adding support for using DNS site names in the existing access synchronization scheme. Just replace the Site IDs with site names.
This would be a good start.

In the perfect world a group LDAP search filter could be specified and the access permissions could be added to a group that matches the filter and then assign permissions based on group memberships. One can dream, right?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant