Приложение A — LDAP: Текстовые поисковые фильтры

Текстовая форма поискового фильтра определена в RFC 4515, немного улучшена в RFC 4510 и значительно расширена с помощью так называемого соответствия компонентов (component matching, RFC3687) и общих правил кодирования строк (Generic String Encoding Rules, GSER, RFC4792).

Примечание: С одной стороны, соответствие компонентов является составной частью основной спецификации LDAPv3 и поэтому не требует OID расширения LDAP (в rootDSE). С другой стороны, соответствие компонентов было определено значительно позже, чем оригинальные спецификации LDAPv3. Поэтому не совсем понятно, насколько широко распространена их реализация и каким образом, кроме как попробовав, можно определить, поддерживает ли какая-то конкретная реализация LDAP эту возможность. componentMatching было анонсировано в OpenLDAP 2.4.8, и включается в сборку только когда установлена переменная окружения LDAP_DEVEL, что в большинстве сборок не является значением по умолчанию. Даже после компиляции с этой переменной не все matchingRules будут доступны — особенно presentMatch. Видимо, соответствие компонентов до сих пор имеет статус "в разработке" (Заметка 5429).

Очевидно, поиск требуется, только если запись не может быть найдена напрямую. То есть, это не то же самое, что 'базовый' DN операций чтения или модификации. Когда запись первоначально добавляется в DIT (как с помощью LDIF-файла, так и через LDAP-клиент), ей ассоциируется DN. В общем случае, во избежание излишних операций поиска, данный DN 'создания' должен быть таким, который чаще всего используется при доступе к записи. Однако, если данная запись используется для аутентификации, то на неё накладываются дополнительные условия.

Основной формат

( filter )

Фильтры всегда заключаются в круглые скобки.

Простые фильтры с одним выражением

attr=value # соответствие (может содержать поисковые шаблоны)
attr~=value # примерное соответствие
attr>=value # больше чем
attr<=value # меньше чем
ИЛИ
objectclass=class

Примечание: Тип проводимого сравнения, например с учётом или без учёта регистра символов, определяется свойствами используемого в сравнении атрибута и формой поиска (может быть EQUALITY, ORDERING или SUBSTR). В некоторых случаях используемая при поиске строка называется substring, это верно лишь в том случае, если она содержит один или несколько поисковых шаблонов. Определение атрибута.

В приведённом выше листинге:

соответствие (=) считается истинным, если найдено либо совпадение EQUALITY (без поисковых шаблонов в value), либо совпадение SUBSTR (при наличии одного или нескольких поисковых шаблонов в value).

примерное соответствие (~=) считается истинным, если найдено совпадение с помощью одного из двух алгоритмов поиска 'созвучных слов'. Требуется индекс типа approx.

больше чем (>=) считается истинным, когда при лексикографическом сравнении value с содержимым указанного атрибута последнее будет лексикографически равно или больше (то есть возвращаются все строки, в которых значение указанного атрибута лексикографически равно или больше value). Данная форма поиска работает только в том случае, если у атрибута есть правило ORDERING, то есть с очень немногими атрибутами.

меньше чем (<=) считается истинным, когда при лексикографическом сравнении value с содержимым указанного атрибута последнее будет лексикографически равно или меньше (то есть возвращаются все строки, в которых значение указанного атрибута лексикографически равно или меньше value). Данная форма поиска работает только в том случае, если у атрибута есть правило ORDERING, то есть с очень немногими атрибутами.

Поисковые шаблоны (wildcard)

Поисковый шаблон * может использоваться отдельно (самостоятельно) как индикатор наличия (то есть в данной записи существует такой атрибут, или в данной записи существует такой объектный класс), либо как классическое итерационное значение, в этом случае его присутствие означает "в позиции * могут находиться 0 или более любых символов". В форме objectclass=obj поисковые шаблоны могут использоваться только в качестве индикатора наличия.

Примеры простых поисковых выражений

(mail=*) # возвращает все записи, у которых есть атрибут mail
(objectclass=*) # возвращает все записи
(mail=*@*) # возвращает записи, значение атрибута mail которых соответствует правильному почтовому адресу формата RFC822
(sn=smith) # возвращает точное соответствие Smith, но НЕ Smit
(sn=s*) # возвращает записи с фамилиями, начинающимися на s или S
(cn=*a*i*) # возвращает записи, в общепринятых именах которых присутствуют сразу a и i в любом месте
(telephonenumber=*555) # возвращает записи с телефонными номерами, оканчивающимися на 555
(objectclass=person) # возвращает записи, в которых используется объектный класс person

Примечания:

При поиске с фильтром objectclass=person также возвращаются записи с любыми объектными классами, использующими в своей иерархии person, например, записи с объектными классами inetOrgPerson или residentialPerson и т.д.
Форма выполнения тестирования также зависит от определения атрибутов (определения ASN.1). Например, sn и cn являются частью семейства атрибутов name, при определении которого задано правило соответствия caseIgnoreMatch, означающее, что соответствие будет искаться БЕЗ учёта регистра символов, то есть при поиске с фильтром sn=a будут найдены и a, и A.

Простые фильтры с комбинированными выражениями

Два или более выражения могут быть объединены (или вложены) с помощью & (логическое И), ! (логическое НЕ) и | (логическое ИЛИ):

(&(exp1)(exp2)(exp3)) # exp1 И exp2 И exp3
(|(exp1)(exp2)(exp3)) # exp1 ИЛИ exp2 ИЛИ exp3
(!(exp1)) # НЕ exp1
(&(!(exp1))(!(exp2))) # НЕ exp1 И НЕ exp2

НЕ (!) смотрится несколько проблематично, зато логично (может быть), и работает только в приведённой выше форме. Смотрите также примеры ниже:

Примеры простых фильтров с комбинированными выражениями

(&(mail=*)(cn=*r)(sn=s*)) # есть атрибут mail И cn заканчивается на R И sn начинается с s
(|(sn=a*)(sn=b*)(sn=c*)) # sn начинается с a ИЛИ с b ИЛИ с c
(!(sn=a*)) # записи с sn НЕ начинающимся с a
(&(!(sn=a*))(!(sn=b*))) # записи с sn НЕ начинающимся с a И НЕ начинающимся с b
(&(sn=*a)(!(sn=s*))) # записи с sn, заканчивающимся на a И НЕ начинающимся с s
# классическия простая ошибка:
(&(sn=a*)(sn=b*)(sb=c*)) # условие невыполнимо, никогда ничего не возвращается

Поиск специальных символов

Если требуется поиск по шаблону, включающему специальные символы (* ) ( \ или NULL), эти символы должны быть экранированы с использованием формата '\code', где code — два шестнадцатеричных символа, представляющие ASCII-код символа. Аналогично поиск по любому двоичному значению может быть осуществлён с помощью его шестнадцатеричного представления.

\2a заменяет или экранирует *
\28 заменяет или экранирует (
\29 заменяет или экранирует )
\5c заменяет или экранирует \
\00 заменяет или экранирует NUL
\xx поиск шестнадцатеричного значения
    где хх лежит в диапазоне 00 - FF

Примеры поиска с использованием экранирования

(cn=*\2a*) # поиск символа *, расположенного в любом месте в cn
(file=d:\5cmyfile.html) # поиск d:\myfile
(description=*\28*\29) # поиск ( и ), расположенных в любом месте, но в этой последовательности
(bin=\5b\04) # поиск двоичного значения 5b04

Расширение возможностей поиска соответствия

Поведение по умолчанию при поиске по любому атрибуту определяется правилами соответствия данного атрибута отдельно для разных типов поиска (EQUALITY, SUBSTR или ODERING). Это поведение может быть переопределено путём указания заменяющего правила соответствия (либо имени правила, либо его OID).

# для sn поведение по умолчанию при сравнении EQUALITY
# caseIgnoreMatch (2.5.13.2)
sn=smith

# переопределим соответствие EQUALITY, чтобы оно зависело от регистра символов
sn:caseExactMatch:=Smith
# то же самое с помощью OID
sn:2.5.13.5:=Smith

# если при поиске встречаются поисковые шаблоны,
# применяется правило соответствия SUBSTR

# для sn поведение по умолчанию при сравнении SUBSTR
# caseIgnoreSubstringMatch
sn=*s* # находит Smith или smith

# переопределим соответствие SUBSTR, чтобы оно зависело от регистра символов
sn:caseExactSubstringMatch:=*S* # находит только Smith
# то же самое с помощью OID
sn:2.5.13.7:=*S*

Используя данный процесс переопределения, можно задавать поисковые критерии, включающие возможности, не определённые в самом атрибуте, такие как ORDERING (которые очень редко встречаются в определениях атрибутов).

Компоненты DN

Существует возможность указать, что любая часть данных из значений атрибутов базового DN может быть также включена в поиск. Это можно сделать с помощью ключевого слова dn внутри поискового выражения, как показано ниже:

# указывает, что значение dc, соответствующее com, может присутствовать в DN 
# или конечная целевая запись определяется базовым DN и диапазоном
dc:dn:=com

Соответствие компонентов (Component Matching) определяется примерно по тому же принципу, что и расширенные фильтры. Оно описано отдельно.

Проблемы, комментарии, предположения, исправления (включая битые ссылки) или есть что добавить? Пожалуйста, выкроите время в потоке занятой жизни, чтобы написать нам, вебмастеру или в службу поддержки. Оставшийся день Вы проведёте с чувством удовлетворения.

Нашли ошибку в переводе? Сообщите переводчикам!