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

feat: implement LDAP service discovery (RFC 2782) #362

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

tonyhhyip
Copy link

@tonyhhyip tonyhhyip commented Mar 21, 2022

feat(discovery): implement LDAP service discovery (RFC 2782)

Closes #329

@vetinari
Copy link
Contributor

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 ldaps:// as URL and it tries to find the server(s) from SRV records. Without docs no-one will discover and/or use this feature.

v3/conn.go Show resolved Hide resolved
v3/conn.go Show resolved Hide resolved
v3/conn.go Show resolved Hide resolved
@vetinari vetinari changed the title Closes #329 implement LDAP service discovery (RFC 2782) Mar 22, 2022
@tonyhhyip tonyhhyip changed the title implement LDAP service discovery (RFC 2782) Draft: implement LDAP service discovery (RFC 2782) Mar 28, 2022
@tonyhhyip
Copy link
Author

tonyhhyip commented Mar 28, 2022

A few more to implement before finalize and write document:

  • a way to append baseDN for every operation
  • decide a way to deal with ldap:///dc=example,dc=com as the standard does not defined this and AD have no implement for LDAPS

@tonyhhyip
Copy link
Author

Not going to special deal with LDAPS for service discovery for now, as the RFC does not define the way of implement for LDAPS

@tonyhhyip
Copy link
Author

Document will be updated once the code are fine and ready

@tonyhhyip tonyhhyip changed the title Draft: implement LDAP service discovery (RFC 2782) feat: implement LDAP service discovery (RFC 2782) May 31, 2022
@cpuschma
Copy link
Member

cpuschma commented Jun 1, 2022

I'm sorry for my delay in responding, alot going on currently. I'll have a look at your changes tomorrow!

Copy link
Member

@cpuschma cpuschma left a 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{
Copy link
Member

@cpuschma cpuschma Jun 12, 2022

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.

Copy link
Author

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

Copy link
Member

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{
Copy link
Member

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{
Copy link
Member

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 {
Copy link
Member

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{
Copy link
Member

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{
Copy link
Member

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) {
Copy link
Member

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

@cpuschma
Copy link
Member

cpuschma commented Jun 12, 2022

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:

  • There are no updated tests
  • No code comments
  • Service discovery only works when using a distinguishedName to connect
  • An entirely new topic was added (feat: implement having rootDN for dialURL)
  • A faulty function which didn't make sense (appendDN)

// Edit:
And perhaps I'm a bit biased now and maybe even a little bit pissed, but I really dislike having one PR entirely missing the point (implementing the RFC) and even adding a completely new unrelated topic:

feat(discovery): implement LDAP service discovery (RFC 2782)
feat: implement having rootDN for dialURL

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

@tonyhhyip
Copy link
Author

I implement this feature based on the description of DNS SRV Records for LDAP. What I would like to implement is for allowing ldap:///dc=example,dc=com could use SRV record _ldap._tcp.example.com

@tonyhhyip
Copy link
Author

And document will be written after the code is ready to accept, I don't want the document is out of sync with code

@johnweldon
Copy link
Member

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'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.

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

Successfully merging this pull request may close these issues.

server discovery by SRV record?
4 participants