Administration Guide › Set Up Views › How Views Work › How the DSA Compares Parameters in Views

How the DSA Compares Parameters in Views

When the DSA replaces a parameter with a value, it transforms the value to a canonical form that is based on the matching rules that are specified for the attribute. Matching rules define how to compare two strings, to test if they are equal, or if one is greater than or less than the other. RFC 4517 defines these matching rules.

All attribute values have associated matching rules. One commonly used rule is the caseIgnoreMatch rule, which says that you can ignore letter case when comparing strings for equality.

When a views parameter is compared to a phase result and the matching rules are not identical, the transformation that the DSA has performed can produce unexpected results. For example, spaces are not important for telephone numbers, so if an attribute is defined with telephoneNumberMatching matching rules, the following entries are equivalent:

+61 3 1300-1001
+61313001001

However, under caseIgnoreMatch rules these two strings do not match.

Similarly, you can invoke a view with the following search command:

ldapsearch... "ph="+613 1300-1001" 

In this case, if ph is defined with telephone number syntax, the DSA stores $ph as follows:

+61313001001

If an account number is stored as a numericString, then the DSA transforms the following result:

ac="+613 1300-1001"

That result is converted to the following numeric string:

61313001001

Because comparisons are performed after the strings are converted, the following comparison fails:

($ac=$ph)