-
Notifications
You must be signed in to change notification settings - Fork 358
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
feat: implement LDAP service discovery (RFC 2782) #362
base: master
Are you sure you want to change the base?
Conversation
Please also add some documentation for the users describing what this does. From taking a quick look at the code I'd guess it allows to use |
A few more to implement before finalize and write document:
|
Not going to special deal with LDAPS for service discovery for now, as the RFC does not define the way of implement for LDAPS |
Document will be updated once the code are fine and ready |
I'm sorry for my delay in responding, alot going on currently. I'll have a look at your changes tomorrow! |
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.
Everything mentioned also counts for v3
search.go
Outdated
@@ -231,6 +231,20 @@ type SearchRequest struct { | |||
Controls []Control | |||
} | |||
|
|||
func (req *SearchRequest) appendBaseDN(dn string) appendDnRequest { | |||
return &SearchRequest{ |
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.
This is an unnecessary allocation. You're working with a pointer to the object anyway, why not edit object in place and simply change the field? E.g.
func (req *SearchRequest) appendBaseDN(dn string) {
req.BaseDN = appendDN(req.BaseDN, dn)
}
This also woldn't require us to constantly update this method in case new fields are added/changed.
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.
As a user, I don't expect my input to be modified by the library, at least, the original version won't. However, there is a way to implement a clone and edit method
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.
Most of the operations in this library mutate the given input. Let's stick with the same approach for now, and if we decide to clone and edit user input in the future we can do that everywhere, rather than inconsistently.
modify.go
Outdated
@@ -82,6 +82,14 @@ func (req *ModifyRequest) appendChange(operation uint, attrType string, attrVals | |||
req.Changes = append(req.Changes, Change{operation, PartialAttribute{Type: attrType, Vals: attrVals}}) | |||
} | |||
|
|||
func (req *ModifyRequest) appendBaseDN(dn string) appendDnRequest { | |||
return &ModifyRequest{ |
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.
Same goes here
moddn.go
Outdated
@@ -50,6 +50,16 @@ func NewModifyDNWithControlsRequest(dn string, rdn string, delOld bool, | |||
} | |||
} | |||
|
|||
func (req *ModifyDNRequest) appendBaseDN(dn string) appendDnRequest { | |||
return &ModifyDNRequest{ |
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.
Same goes here
dn.go
Outdated
@@ -268,3 +268,15 @@ func (r *RelativeDN) hasAllAttributesFold(attrs []*AttributeTypeAndValue) bool { | |||
func (a *AttributeTypeAndValue) EqualFold(other *AttributeTypeAndValue) bool { | |||
return strings.EqualFold(a.Type, other.Type) && strings.EqualFold(a.Value, other.Value) | |||
} | |||
|
|||
func appendDN(baseDN, rootDN string) string { |
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.
baseDN
isn't appended by rootDN if it isn't empty.
appendDN("ou=base", "dc=test,dc=org")
would result in ,dc=test,dc=org
, which in turn is a invalid DN syntax.
Also, may you add some documentation what this function is exactly for and what baseDN and rootDN stand for
del.go
Outdated
@@ -12,6 +12,13 @@ type DelRequest struct { | |||
Controls []Control | |||
} | |||
|
|||
func (req *DelRequest) appendBaseDN(dn string) appendDnRequest { | |||
return &DelRequest{ |
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.
Same goes here
add.go
Outdated
@@ -33,6 +33,14 @@ type AddRequest struct { | |||
Controls []Control | |||
} | |||
|
|||
func (req *AddRequest) appendBaseDN(dn string) appendDnRequest { | |||
return &AddRequest{ |
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.
Same goes here
@@ -144,35 +148,87 @@ type DialContext struct { | |||
tc *tls.Config | |||
} | |||
|
|||
func (dc *DialContext) dial(u *url.URL) (net.Conn, error) { | |||
func (dc *DialContext) dial(u *url.URL) (conn net.Conn, err error) { |
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.
May you update the related tests and add some comments for documentation. The newly added functionality isn't really self-explanatory, especially when it comes down to the rootDN
and baseDN
I also want to mention that this PR doesn't satisfy RFC 2782, as it only covers using the SRV records when using the distinguishedName of the directory server as hostname to connect to, which isn't covered by the RFC document or by any other. May you please point us to the correlated document here? Sorry if this might sound a bit harsh, but I really didn't quite get what you tried to do here, because I was constantly comparing your changes with the mentioned RFC document and was like: What are you trying here.. especially because:
// Edit:
Maybe if another maintainer could step in and give in his 5 cents please, if we should continue adding work to this PR or if this is "burned grounds". @stefanmcshane @johnweldon @vetinari |
I implement this feature based on the description of DNS SRV Records for LDAP. What I would like to implement is for allowing |
And document will be written after the code is ready to accept, I don't want the document is out of sync with code |
I'm inclined to agree about not accepting a PR that 1) mixes several changes together, and 2) implements an RFC incorrectly, or incompletely to the point of being detrimental. @tonyhhyip it seems like you opened this PR as a starting point for discussion? Let's take some time and figure out what needs to change. First, let's move the append base DN to a new PR (I'd rather see it exposed as a user-optional feature, than have it baked in), and get that implemented to satisfaction, then let's revisit this to see that RFC 2782 is adequately considered. |
feat(discovery): implement LDAP service discovery (RFC 2782)
Closes #329