connector/ldap: treat attributes as case-insensitive all the way #1251
+105
−6
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
LDAP itself doesn't match attributes case-sensitively, so a query for
(fOO=bar)
will return all the entries having `foo: bar`, regardless of how the
attribute name is defined in the schema.
However, the result entries we get will have the case according to what
the server returned. So, assuming the schema calls it `foo`, this is
what we're given.
Now, for certain attributes that are user-configurable -- NameAttr for
example -- this can cause trouble: the query returns the right results,
but the LDAP connector can't make sense of it as it's looking for an
attribute called `fOO`.
The real life case underlying this conundrum is Active Directory's
sAMAccountName.
Note that this is a bit of a workaround. Ideally, we'd use
`(*ldap.Entry).GetAttributes(string) []string` to access the attributes;
but until the case sensitivity issue is fixed there[1], changing the way
we read the results doesn't help us.
[1]: go-ldap/ldap#111
Signed-off-by: Stephan Renatus <srenatus@chef.io>
|
Does anyone have a moment to consider this, please? 😃 |
|
@ericchiang Another small LDAP improvement I'd like to get in. Any thoughts? 😃 |
|
Just started reading http://www.zytrax.com/books/ldap/ |
|
@sks I frequently find https://ldapwiki.com/ quite useful, too. 😃 |
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.
LDAP itself doesn't match attributes case-sensitively, so a query for
will return all the entries having
foo: bar, regardless of how theattribute name is defined in the schema.
However, the result entries we get will have the case according to what
the server returned. So, assuming the schema calls it
foo, this iswhat we're given.
Now, for certain attributes that are user-configurable -- NameAttr for
example -- this can cause trouble: the query returns the right results,
but the LDAP connector can't make sense of it as it's looking for an
attribute called
fOO.The real life case underlying this conundrum is Active Directory's
sAMAccountName.
Note that this is a bit of a workaround. Ideally, we'd use
(*ldap.Entry).GetAttributes(string) []stringto access the attributes;but until the case sensitivity issue is fixed there1, changing the way
we read the results doesn't help us.