Рефералы - стоит ли слепо следовать стандартам?

LDAP
При «склеивании» распределённого LDAP-каталога с помощью объектов класса referral, нужно обязательно помнить о том, что в базовом случае, без дополнительных настроек, вся логика обработки ссылки, указанной в атрибуте ref, реализуется на стороне клиента. Это вроде бы очевидно, и тем не менее обязательно нужно понимать концептуальные следствия такого подхода. А главным следствием здесь является то, что если LDAP-серверы ещё худо-бедно подчиняются стандартам (не будем смотреть на CommuniGate LDAP и подобные «имитации» с крайне узкой сферой применения), то LDAP-клиенты, в особенности встроенные-во-что-то-ещё, реализуют как правило лишь самые основные возможности протокола, к числу которых referral'ы по мнению многих нерадивых разработчиков не относятся. Также могут возникнуть проблемы с клииентами, которые понимают referral'ы, но в буквальном смысле слова теряют bindDN и userPassword и пытаются переходить на связанные рефералами уровни без credentials, то есть анонимно.
Таким образом, реализация распределённого каталога, опирающаяся исключительно на стандарты, закладывается на интеллектуальную логику клиента работы со ссылками, смещая акценты стандартизации в сторону приложений, где они, эти проблемы, по жизни как раз стоят наиболее остро. Это источник проблем несовместмости, решение которых по идее является одной из задач протокола.
Вывод: используйте нестандартные расширения на стороне сервера, наподобие overlay chain в OpenLDAP, которые делают работу с распред. каталогом полностью прозрачной для клиентских приложений — иначе вам придется насильно подгонять под стандарты ваши приложения, что в идеале правильно, но в реальности — занятие крайне неблагодарное.

0 комментариев

Только зарегистрированные и авторизованные пользователи могут оставлять комментарии.