LDAP: rework configuration and move to a common module #2708
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Thanks for opening this pull request! The maintainers of this repository would appreciate it if you would create a changelog item based on your changes. |
rhafer
force-pushed
the
share-ldap-conn
branch
8 times, most recently
from
d227818
to
449f676
Compare
rhafer
requested review from
labkode,
ishank011,
glpatcern and
a team
as code owners
kobergj
requested changes
Apr 1, 2022
kobergj
requested changes
Apr 5, 2022
wkloucek
approved these changes
Apr 11, 2022
Instead of open a new connection with every single requests. We now use a long-lived connection per service with a simple mechanism to automatically reconnect in case of failures. Fixes cs3org#2122
This reworks the LDAP configuration of the user- and groups-providers. As the LDAP groups provider needs to be aware of users (e.g. for looking up groups members) and the LDAP users provider needs to be aware of groups (e.g. for looking up groupmembership of a user) this commit basically unifies the configuration of both providers. Additionally the LDAP configuration is reworked to no longer rely on templating LDAP filters in the configuration with can be error prone and confusing. This commit also move all code executing LDAP queries into the common utlis/ldap module for being able to share more code between both providers.
Depending on the configured group_objectclass we can no resolve group members by DN as well. Closes: 2124
GetUser() was used to lookup users by name or ID, however it is only supposed to work for ID based lookups. If the ID based lookup fails fallback to an explicit GetUserByClaim fall for trying a name based lookup.
rhafer
added a commit
to rhafer/ocis
that referenced
this pull request
Apr 11, 2022
webUISharingInternalGroupsEdgeCases/shareWithGroupsEdgeCases.feature:41 no longer fails as cs3org/reva#2708 fixed some issue with LDAP filter escaping.
rhafer
added a commit
to rhafer/ocis
that referenced
this pull request
Apr 11, 2022
webUISharingInternalGroupsEdgeCases/shareWithGroupsEdgeCases.feature:41 no longer fails as cs3org/reva#2708 fixed some issue with LDAP filter escaping.
This was referenced May 3, 2022
Merged
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This reworks the LDAP configuration of the user- and groups-providers.
As the LDAP groups provider needs to be aware of users (e.g. for
looking up groups members) and the LDAP users provider needs to be aware
of groups (e.g. for looking up groupmembership of a user) this commit
basically unifies the configuration of both providers.
Additionally the LDAP configuration is reworked to no longer rely on
templating LDAP filters in the configuration with can be error prone and
confusing.
This commit also move all code executing LDAP queries into the common
utlis/ldap module for being able to share more code between both
providers.
Instead of open a new connection with every single requests. We now use
a long-lived connection per service with a simple mechanism to
automatically reconnect in case of failures.