Require explicit intention for empty password. #126
Conversation
This is normally used for unauthenticated bind, and https://tools.ietf.org/html/rfc4513#section-5.1.2 recommends: > Clients SHOULD disallow an empty password input to a Name/Password > Authentication user interface
There was a problem hiding this comment.
I appreciate the fix, and the refactor. LGTM
@liggitt how do you want to handle the implicit API change? (no explicit breakage, but existing clients may rely on unauthenticated bind implicitly triggered by no password)
I think this is just a matter of a new version tag?
Definitely a new version tag. I'd like it to be a major version, but there were other breaking changes I wanted to see in the 3.0 bump that I don't have bandwidth to do in the next few days. I'm ok merging this into master, starting a v2 maintenance branch just prior to this, and holding tagging a 3.0 release until the other cleanup tasks are done |
|
I'll merge to master and open a new v2 maintenance branch just prior to this merge. |
During the code reshuffle in go-ldap#126 at bind time a call to encodeControls was added. Unfortunately, the safety check around calling it when there are no controls to encode were omitted from this call (unlike in del.go and search.go). As a result the packet was always getting control characters added even if there were none to encode. I also modified the checks in del.go and search.go to be a little safer; rather than check for a nil slice, it also will do the right thing when the slice is not nil but there are no entries.
This is normally used for unauthenticated bind, and
https://tools.ietf.org/html/rfc4513#section-5.1.2 recommends: