-
-
Notifications
You must be signed in to change notification settings - Fork 4.2k
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
fixes possible override of uniqueMember by autodetection #15604
fixes possible override of uniqueMember by autodetection #15604
Conversation
* uniqueMember was the default so we did not know whether this setting is desired or the initial value * autodetection of the user-group association attribute runs only when it was not set (as far as we knew) * the default is now empty * thus LDAPProvider might return this value as well (in exceptional cases) * if a group base is given (edge case), use this instead of general base * resolves #12682 Signed-off-by: Arthur Schiwon <blizzz@arthur-schiwon.de>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Code change makes sense 👍
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I could not test. But it makes some sense to me with my limited LDAP knowledge
Signed-off-by: Arthur Schiwon <blizzz@arthur-schiwon.de>
Still unsure about the backports. It's not the proper way. |
Let's leave it for 17. I'll just respond it's fixed but not backportable since default values change. |
desired or the initial value
was not set (as far as we knew)
It changes behaviour a bit:
uniqueMember
is not so common, and neither is not hitting "count groups". Imho, only impact for auto-installations were the attribute is not set specifically.I would say it is still OK to backport… more to the rules is to keep for 17 only though. The impact is small and rather beneficial.
What's left