Filter with extensible Match Rule fails validation when the rule changes the expected value type

[jtgasper3]

Some directory varieties support additional match rules: https://docs.oracle.com/cd/E19476-01/821-0509/relative-time-matching-rules.html, when using these match rules the expected right-hand side value is not longer a Generalized Time format, but an alternative date format (See the doc listed above):

(createTimestamp:1.3.6.1.4.1.26027.1.4.5:=-365d) and (createTimestamp:relativeTimeGTOrderingMatch:=-90w) fail with:

File "/usr/local/lib/python3.8/site-packages/ldap3/protocol/convert.py", line 177, in validate_attribute_value
    raise LDAPInvalidValueError('value \'%s\' non valid for attribute \'%s\'' % (value, name))
ldap3.core.exceptions.LDAPInvalidValueError: value '-90w' non valid for attribute 'createTimestamp'

I can work around this by removing the attribute from the schema and adding it to ATTRIBUTES_EXCLUDED_FROM_CHECK:

    attrs = get_config_parameter('ATTRIBUTES_EXCLUDED_FROM_CHECK')
    attrs.extend(["createTimestamp"])
    set_config_parameter('ATTRIBUTES_EXCLUDED_FROM_CHECK', attrs)
...
    conn.server.schema.attribute_types.pop("createTimestamp")

Tested with ldap3 2.7 and 2.8.1`. Am I missing a more appropriate method for working through this?

Note: I'm not sure if this is associated with issue #862 or not.

[cannatag]

Hi, that's the right way to do it for now. An alternative way is to write a formatter function and a validator function for this attribute type. It's not difficult to write but I cannot test it against a real server. If you want to test it I can try.

[quanah]

In general, I think the attempts to have ldap3 do filter validation is problematic. OpenLDAP also implements a number of custom matching rules (dnSubtreeMatch is one example). These are internally defined so there is not an external schema file for these. Additionally OpenLDAP modules (ppolicy being one example) define their schema internally to the module, so there is no external schema file to use for validation (This is new with OpenLDAP 2.5+). I guess for now users can use the above trick to exclude things such as this as necessary, but it's going to be a larger problem any time filters are being validated against internally defined attributes and matching rules.