- Use more strict comparisons for client input asserts
- Fix baseObject comparison in SearchRequest initialization
- Alter default error for server route fallthrough
Some LDAP implementations (mainly AD and Outlook) accept and/or output
DNs that are not valid. To support interaction with these invalid DNs a
strictDN flag (default: true) has been added to the client and server
constructors. Setting this flag to false will allow use of
non-conforming DNs.
When disabling strictDN in the ldapjs client, strings which wouldn't
parse into a DN can then be passed to the ldap operation methods. It
also means that some methods (such as search) may return results with
string-formatted DNs instead of DN objects.
When disabling strictDN in the ldapjs server, incoming requests that
contain invalid DNs will be routed to the default ('') handler for that
operation type. It is your responsiblity to differentiate between
string-type and object-type DNs in those handlers.
Fixmcavage/node-ldapjs#222Fixmcavage/node-ldapjs#146Fixmcavage/node-ldapjs#113Fixmcavage/node-ldapjs#104
Certain LDAP messages (such as DeleteRequest) encode their contents as
raw bytes within the top-level sequence object. As such, they rely
their length being passed to them when LDAPMessage decodes the sequence.
This was being done incorrectly, but would not manifest itself as a
problem unless controls followed the message. If no controls were
present, then length of the sequence item was bounded by the message
itself and the parse would succeed.
Fixmcavage/node-ldapjs#212
In cases where one side of the connection is not communicated with valid
ASN.1/BER, it would be better to fire an error event rather than let the
exception bubble all the way up.
Fixmcavage/node-ldapjs#142
Buffertools 2.0.1 is required to build on VC2013.
With the change to v2.x, the buffertools.extend() method must be called
to mimic the prototype extention behavior of the 1.x versions.
Fixmcavage/node-ldapjs#163