filter is case sensitive

[axkibe]

Following minimal testcase:

const ldap = require( 'ldapjs' );
const attr = {};
attr.cn = 'axel';
attr.gidNumber = '1001';
attr.uidNumber = '1001'
attr.uid = 'axel';
attr.displayName = 'axel';
attr.loginShell = '/bin/bash';
attr.homeDirectory = '/home/axel';
attr.objectclass = [ 'posixAccount', 'top' ];
const f = ldap.parseFilter('(objectClass=*)');
console.log( f.matches( attr ) );

The result with node-ldapjs 2.3.3 is true, in node-ldapjs 3.0.1 it is false.

Note the uppercase C, writing it lowercase gives the IMO correct true (or changing the attribute to match the same case)

AFAIK LDAP is supposed to be case insensitive on attributes by default, as 2.3.3 did, no?

[jsumners]

LDAP filter strings are defined by https://www.rfc-editor.org/rfc/rfc4515

LDAP attributes (<attributedescription> = <attributevalue>) are defined by https://www.rfc-editor.org/rfc/rfc4512#section-2.5 and https://www.rfc-editor.org/rfc/rfc4512#section-2.5.1. Specific to this issue:

Both <attributetype> and <option>
productions are case insensitive. The order in which s
appear is irrelevant. That is, any two <attributedescription>s that
consist of the same <attributetype> and same set of <option>s are
equivalent.

So it can be correct to say that objectclass === objectClass when comparing two attributes.

Scattered throughout the ldapjs <= 2 code were blocks that looked like:

if (prop.toLowerCase() === 'objectclass') {
  // do some check or something
}

Such blocks would have a comment attached like:

// Comparing case insensitive since most implementations do that for objectClass

To be clear: the ldapjs <= 2 code made an explicit exception for objectClass. For all other attribute types it defaulted to case sensitive comparisons.

In general, the spec is muddy on what to do in regard to attribute type comparisons. The closest we get is the discussion around the compare operation and the ensuing descriptions of various filters -- https://www.rfc-editor.org/rfc/rfc4511#section-4.10.

However, we retained the original case insensitive comparison feature:

const ldap = require( 'ldapjs' );
const attr = {};
attr.cn = 'axel';
attr.gidNumber = '1001';
attr.uidNumber = '1001'
attr.uid = 'axel';
attr.displayName = 'axel';
attr.loginShell = '/bin/bash';
attr.homeDirectory = '/home/axel';
attr.objectclass = [ 'posixAccount', 'top' ];
const f = ldap.parseFilter('(objectClass=*)');
console.log(
  f.matches( attr, false )
);

Note the inclusion of a second parameter being passed to f.matches. See the following declaration in the AND filter as an example:

filter/lib/filters/and.js

Lines 54 to 73 in e70a7cb

	/**
	* Determines if an object represents an equivalent filter instance.
	* Both the filter attribute and filter value must match the comparison
	* object. All clauses of the `AND` filter, that is all "sub filters", must
	* match for the result to be `true`.
	*
	* @example
	* const eqFilter = new EqualityFilter({ attribute: 'foo', value: 'bar' })
	* const filter = new AndFilter({ filters: [eqFilter] })
	* assert.equal(filter.matches({ foo: 'bar' }), true)
	*
	* @param {object} obj An object to check for match.
	* @param {boolean} [strictAttrCase=true] If `false`, "fOo" will match
	* "foo" in the attribute position (left hand side).
	*
	* @throws When input types are not correct.
	*
	* @returns {boolean}
	*/
	matches (obj, strictAttrCase = true) {

[axkibe]

Thanks for your detailed explanation.

I searched if I rather should set "objectclass" or "objectClass" and it seems the internet is all over the place. Basically as workaround other than ,false as second parameter I can also set both attributes.

[jsumners]

I have updated the v3 release notes with this information.