Я просматривал исходный код OpenLDAP и видел, где корневая DSE поддерживает так называемые абсолютные фильтры. Похоже, это указано в RFC4526 Похоже, что автор, который изначально составлял его, работал над проектом OpenLDAP, поэтому я не знаю, полезно ли это для этой конкретной реализации или что-то в этом роде.
Во всяком случае, RFC дает такое определение:
An 'and' filter consisting of an empty set of filters SHALL evaluate
to True. This filter is represented by the string "(&)".
An 'or' filter consisting of an empty set of filters SHALL evaluate
to False. This filter is represented by the string "(|)"
Мой вопрос: в чем польза от этого? Я не могу вспомнить ни одного примера, где это дает возможность делать то, что вы не могли сделать раньше. Если вы хотите абсолютного AND тогда ты не можешь сделать (objectClass=*) фильтровать, поскольку все записи должны иметь хотя бы один класс объектов?
Единственное, для чего я могу придумать применение, это Absolute False. Может случиться так, что вы просто хотите, чтобы сервер не работал, чтобы убедиться, что связь по-прежнему работает нормально. Это все еще в некотором роде избыточно, поскольку я думаю, что запрос корневого DSE и отбрасывание результатов будут делать то же самое и не могут быть такими дорогостоящими в вычислительном отношении.
Использование фильтра в ldapsearch дает результаты, которые, я думаю, я должен ожидать, учитывая приведенное выше:
[root@hypervisor openldap]# ldapsearch -x -H ldap://policyServer.trunkator.com -b '' -s base "(|)" +
# extended LDIF
#
# LDAPv3
# base <> with scope baseObject
# filter: (|)
# requesting: +
#
# search result
search: 2
result: 0 Success
# numResponses: 1
[root@hypervisor openldap]#
Использование фильтра absolute true возвращает то же самое, как если бы я сделал (objectClass=*) (который является фильтром по умолчанию для OpenLDAP ldapsearch client, если вы не укажете его в командной строке).
Согласно RFC, они удалили их из исходного LDAPv3 RFC, и поэтому автор столкнулся с проблемой их добавления обратно. в и мне просто интересно, почему (я уверен, что причина есть).
Любые идеи?
РЕДАКТИРОВАТЬ:
Немного неудачной формулировки вверху: когда я говорю «корневой DSE поддерживает», более ясный способ сказать это то, что корневой DSE в OpenLDAP жестко запрограммирован, чтобы сообщить, что он поддерживает абсолютные фильтры.
В разделах «Аннотация» и «Предпосылки» RFC четко указано, что эта функция не была реализована в LDAP v3. Концепция абсолютных фильтров, по-видимому, является частью X.500 / DAP, и они призваны помочь при запросе записей, специфичных для DSA, с которыми может не быть связан объектный класс. Хотя это, очевидно, не является специфической функцией производителя, ее реализация оставлена на усмотрение поставщика (например, OpenLDAP, похоже, реализовал ее). Кажется не очень полезным, если используемое программное обеспечение каталога связывает все записи, включая специфичные для DSA, с объектным классом (например, top), что делает фильтр '(objectclass = *)' функционирующим так, как будто это абсолютный фильтр что приводит к "истине". Если программное обеспечение каталога не связывает записи, относящиеся к DSA, с объектным классом или другим атрибутом, конкретное значение которого при поиске принимает значение «истина», тогда абсолютный фильтр, действующий как переключатель истинно / ложно, становится своего рода обязательной функцией ( если программное обеспечение каталога не предоставляет проприетарный способ получения таких записей, что, вероятно, не является хорошей идеей, поскольку такая нестандартная реализация вынудит клиентов LDAP быть ограниченными / специфичными для поставщика).
Я подозреваю, что это упрощает определенные программные конструкции. Например, если вы создаете в своем коде выражения фильтра следующим образом:
filter_string='(&'
for filter in filters:
filter_string = filter_string + '(' + filter + ')'
filter_string = filter_string + ')'
... то в случае, если у вас нет фильтров, вы заканчиваете (&), и часть RFC, которую вы выделили, определяет, как это должно себя вести. То же самое верно и для (|).