Detecting certain types of errors in encountered during any operation
(such as BusyError or UnavailableError) can be useful for making
client-wide decisions.
Search response objects now include more instrumentation and control when
automatically fetching paged results. See the SearchPager documentation
for more details.
Fixmcavage/node-ldapjs#203
In cases where a reconnect-enabled client has been manually disconnected
via unbind, it may be desirable to initiate a reconnect without
incurring other client actions.
The old Attribute.isAttribute would allow objects lacking the toBer
method to be attached to Change objects. This would result in errors
during serialization.
With the stricter Attribute detection, it's necessary to convert
Attribute-like objects containing type (string) and vals (array)
properties into real Attribute objects. This precise detection is
necessary to avoid falling back to the object-keys-into-attributes
That other logic which will turn a well structured Attribute-like object
such as this:
{ type: 'valid', vals: ['something'] }
... and turn it into something broken like this:
[
{ type: 'type', vals: ['valid'] },
{ type: 'vals', vals: ['something'] }
]
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
The pooled client would automatically bind when initializing connections
if bindDN and bindCredentials were passed to during construction.
This convenience should be supported in the plain client too.
Abandon handling is not within spec in the ldapjs server and not
particularly robust in the client. This test should be re-enabled when
both issues are fixed.
If the client queue was enabled and requests were made during the
reconnect process (but after one unsuccessful connection attempt), they
would spawn concurrent reconnection attempts.
A client configured to reconnect should do so on socket close unless
unbind was called explicitly. This covers cases where the connection
undergoes clean but unexpected termination.
- Emit setupError for errors during client setup
- Client accepts more generic options.reconnect
- Fix unbind hang in client.destroy
- Add tests for client reconnect/setup scenarios
Patrick Mooney
Hugo Dozois