| Каталог документации / Раздел "Сети, протоколы, сервисы" / Оглавление документа |
| |
|
Нормальная текстовая форма поискового фильтра определена в RFC 4515, немного улучшена в RFC 4510 и описывается здесь. Поисковые фильтры были значительно расширены с помощью так называемого соответствия компонентов (component matching, RFC3687) и общих правил кодирования строк (Generic String Encoding Rules, GSER, RFC4792).
Примечание: Как уже было сказано, соответствие компонентов — часть основной спецификации LDAPv3, и потому не требует SupportedExtension OID. С другой стороны, соответствие компонентов было определено значительно позже, чем оригинальные спецификации LDAPv3. Поэтому не совсем понятно, каким образом, кроме как попробовав (или произведя поиск componentMatchingRule в ветке matchingRules в rootDSE), можно определить, поддерживает ли какая-то конкретная реализация LDAP, утверждающая, что она совместима с LDAPv3, эту возможность. Можно предположить, что серверы LDAP, в которых декларируется совместимость с RFC серии 45XX, должны поддерживать соответствие компонентов, а те из них, которые совместимы с более ранними RFC серии 225X, скорее всего — нет. В общем, бардак.
Что касается OpenLDAP — здесь всё находится в развитии. Утверждалось, что соответствие компонентов будет реализовано в OpenLDAP 2.4.8, но это не так.
Соответствие компонентов позволяет выполнять поиск по компонентам сложного (составного) атрибута, такого как member, путём явной ссылки на них (или их извлечения). Первопричина разработки данного синтаксиса правил соответствия предположительно связана с необходимостью дополнительной обработки сертификатов X.509. Для этой цели данный синтаксис позволяет пользователю спуститься до уровня ASN.1-деталей требуемого атрибута и ссылаться на содержимое грамматик SEQUENCE OF, SEQUENCE, SET OF и SET. Такой уровень детализации может потребовать перекрёстных ссылок на несколько документов серии X.5xx (как минимум, X.501 и X.520).
Однако, соответствие компонентов также предоставляет более читабельный (хотя и более длинный) синтаксис, особенно для нормальных комбинированных выражений, который может оказаться полезным для пользователя. Чтобы упростить описание данной возможности (как для нас самих, так и для всех читателей), мы решили отдельно описать простые и комплексные выражения соответствия компонентов.
В функции соответствия компонентов представлены два новых правила соответствия: rdnMatch (1.2.36.79672281.1.13.3), позволяющее обработку RDN в DN, и presentMatch (1.2.36.79672281.1.13.5), возвращающее TRUE, если целевой атрибут извлекаемого компонента существует, эквивалентно фильтру наличия attr=* в нормальных поисковых фильтрах.
Простое соответствие компонентов определяется либо как альтернативный синтаксис для поиска простого атрибута (значение которого представляет собой один элемент), либо для поиска компонента, извлечённого из комплексного атрибута (значение которого представляет собой несколько элементов), определённого с помощью грамматик ASN.1 SEQUENCE OF или SET OF — в основном, для атрибутов, содержащих несколько компонентов одного и того же типа.
(attr:componentFilterMatch:=[boolexp:{]
item:{[component comexp] [useDefaultValues TRUE|FALSE] rule
matchingRule value valexp } [next-item ... }] )
Поисковый фильтр заключён в круглые скобки, а элементы фильтра соответствия компонентов заключены в фигурные скобки {}.
В следующих подразделах описывается синтаксис соответствия компонентов при использовании в простых выражениях. При использовании в комплексных выражениях возможны дополнительные детали. Синтаксис может быть невообразимо сложным, — не отчаивайтесь, — лучше посмотрите сначала простые примеры, в которых показаны синтаксисы нормальных фильтров и правил соответствия компонентов, а затем возвращайтесь к формальным определениям.
Имя атрибута, по которому будет производиться поиск. Это может быть простой или сложный (составной) атрибут, или операционный атрибут.
Правило соответствия для выполнения функции соответствия компонентов.
Необязательное логическое выражение, возможные варианты 'and:', 'or:' или 'not:'. Логические выражения заключаются в фигурные скобки {}, могут быть вложенными и предварять очень сложные выражения.
Ключевое слово item означает начало component-выражения, заключённого в фигурные скобки {}.
Необязательное ключевое слово component, за которым следует выражение извлечения (или изоляции) компонентов. Если это ключевое слово пропущено, подразумевается, что поисковый фильтр будет ссылаться на атрибут attr целиком, то есть, компоненты извлекаться не будут и такой фильтр превращается просто в альтернативный синтаксис определения поиска. Если component-выражение присутствует, то тип извлекаемого им компонента определяется при применении правила rule.
Выражение извлечения компонента. Может быть простым значением, заключённым в кавычки, либо вложенным выражением item. Простые, заключённые в кавычки значения, могут быть следующими:
число — определяет номер экземпляра компонента согласно грамматике SET OF или SEQUENCE OF
в определении атрибута. В случае, когда атрибут содержит DN, экземплярами,
определёнными в SEQUENCE OF, будут RDN. Самому правому RDN присваивается номер 1,
следующему — номер 2 и т.д. Так в DN ou=me,dc=my,dc=us RDN dc=us будет иметь номер
экземпляра "1", dc=my — "2" и ou=me — "3". Экземпляры именуются справа налево.
отрицательное
число — аналогично предыдущему, только "-1" соответствует самому левому экземпляру.
Так в DN ou=me,dc=my,dc=us RDN ou=me будет иметь номер экземпляра "-1",
dc=my — "-2" и dc=us — "-3". Экземпляры именуются слева направо.
количество — значение "0" указывает, что последующие тесты будут применяться по отношению
к количеству экземпляров компонента в атрибуте, а не к значениям этих экземпляров.
все — значение "*" указывает, что будут использованы все экземпляры компонентов атрибута.
Необязательное значение (по умолчанию TRUE). Определяет, будут ли значения по умолчанию для атрибута (если таковые определены) использоваться (в случае TRUE) при сравнении в component-выражении, или нет (в случае FALSE).
За ключевым словом rule следует правило соответствия (matchingRule), которое будет применено к извлечённому компоненту.
Правило соответствия, которое будет применено к извлечённому компоненту. Может определяться по имени или OID. Правило соответствия должно четко соответствовать извлеченным компонентам.
За ключевым словом value следует то value-выражение, которое будет использоваться при сравнении в данном поисковом фильтре.
Заключённое в кавычки value-выражение, которое будет использоваться при сравнении в данном поисковом фильтре, либо значение NULL, применяемое только с правилом соответствия presentMatch.
Соответствие компонентов в следующих примерах используется как альтернативный синтаксис для уже показанных ранее нормальных поисковых фильтров.
# нормальный поисковый фильтр
(mail=*) # возвращает все записи, у которых есть атрибут mail
# синтаксис соответствия компонентов
(mail:componentFilterMatch:=item:{rule presentMatch, value NULL})
# presentMatch возвращает TRUE если компонент есть в наличии, иначе FALSE
# отрицательная форма (возвращает все записи, у которых НЕТ атрибута mail)
(mail:componentFilterMatch:=not:{item:{rule presentMatch, value NULL}})
# нормальный поисковый фильтр
(mail=*@*) # возвращает записи, значение атрибута mail которых соответствует правильному почтовому адресу формата RFC822
# синтаксис соответствия компонентов
(mail:componentFilterMatch:=item:{rule caseIgnoreMatch, value "*@*"})
# нормальный поисковый фильтр
(&(mail=*)(cn=*r)(sn=s*)) # есть атрибут mail И cn заканчивается на R И sn начинается с s
# синтаксис соответствия компонентов
()
# нормальный поисковый фильтр
(|(sn=a*)(sn=b*)(sb=c*)) # sn начинается с a ИЛИ с b ИЛИ с c
# синтаксис соответствия компонентов
(sn:componentFilterMatch:=or:{item:{rule caseIgnoreMatch, value "a*"},
item:{rule caseIgnoreMatch, value "b*"},
item:{rule caseIgnoreMatch, value "c*"}})
# нормальный поисковый фильтр
(!(sn=a*)) # записи с sn НЕ начинающимся с a
# синтаксис поиска компонентов
(sn:componentFilterMatch:=not:{item:{rule caseIgnoreMatch, value "a*"}})
# нормальный поисковый фильтр
(&(!(sn=a*))(!(sn=b*))) # записи с sn НЕ начинающимся с a И НЕ начинающимся с b
# синтаксис поиска компонентов
(sn:componentFilterMatch:=and:{item:{rule caseIgnoreMatch, value "a*"},
not:{item:{rule caseIgnoreMatch, value "b*"}}})
# нормальный поисковый фильтр
# переопределим соответствие EQUALITY, чтобы оно зависело от регистра символов
sn:caseExactMatch:=Smith
# то же самое с помощью OID
sn:2.5.13.5:=Smith
# синтаксис поиска компонентов
(sn:componentFilterMatch:=item:{rule caseExactMatch, value "Smith"})
# или
(sn:componentFilterMatch:=item:{rule 2.5.13.5, value "Smith"})
В следующих примерах извлекаются компоненты из составного атрибута — в данном случае, DN-атрибут, такой как member:
# Во всех примерах подразумевается, что значение member в формате
# cn=groupname,ou=groups,dc=example,dc=com
# где groupname - переменная
# находим записи с атрибутом member, в котором cn = sales
# в качестве выражения извлечения используем число
# (компоненты нумеруются справа налево)
(cn:componentFilterMatch:=item{component "4",rule rdnMatch, value "cn=sales"})
# находим записи с атрибутом member, в котором cn = sales
# в качестве выражения извлечения используем отрицательное число
# (компоненты нумеруются слева направо)
(cn:componentFilterMatch:=item{component "-1",rule rdnMatch, value "cn=sales"})
# находим записи с атрибутом member, в котором ou = groups
# в любом месте dn
# в качестве выражения извлечения используем синтаксис все
(cn:componentFilterMatch:=item{component "*",rule rdnMatch, value "ou=groups"})
# находим в записи, у которых в атрибуте member 5 компонентов
# в качестве выражения извлечения используем синтаксис count
(cn:componentFilterMatch:=item{component "0",rule rdnMatch, value "5"})
# находим в записи, у которых в атрибуте member 5 и более, но менее 8-ми компонентов
# в качестве выражения извлечения используем синтаксис count
(cn:componentFilterMatch:=or:{item{component "0",rule rdnMatch, value "5"},
item{component "0",rule rdnMatch, value "6"},
item{component "0",rule rdnMatch, value "7"}})
# находим в записи, у которых в атрибуте member есть и cn=sales, и dc=example, и dc=com
# используем составное выражение
(cn:componentFilterMatch:=and:{item:{component "4",rule rdnMatch, value "cn=sales"},
item:{component "2",rule rdnMatch, value "dc=example"},
item:{component "1",rule rdnMatch, value "dc=com"}})
Мы дадим Вам знать, когда сами с этим разберёмся. Но не обещаем, что это будет скоро.
Проблемы, комментарии, предположения, исправления (включая битые ссылки) или есть что добавить? Пожалуйста, выкроите время в потоке занятой жизни, чтобы написать нам, вебмастеру или в службу поддержки. Оставшийся день Вы проведёте с чувством удовлетворения.
Нашли ошибку в переводе? Сообщите переводчикам!
Copyright © 1994-2017 ZyTrax, Inc. Все права защищены. Последнее изменение страницы: 21 октября 2015 г.
Переведено участниками проекта Pro-LDAP.ru в 2012-2013 г.
|
Закладки на сайте Проследить за страницей |
Created 1996-2024 by Maxim Chirkov Добавить, Поддержать, Вебмастеру |