Как хранить простые пары значений и имен в каталоге ldap - PullRequest
Новая
       9

Как хранить простые пары значений и имен в каталоге ldap

4 голосов
/ 11 октября 2009

Я создаю бэкэнд ldap репозитория пользователей для серии веб-приложений, использующих одних и тех же пользователей Я хотел бы хранить информацию о предпочтениях в этом местоположении ldap. Таким образом, все, что связано с пользователями, сохраняется в одном месте и может использоваться всеми приложениями.

Я думаю об общей структуре, подобной этой: 

ou=People,dc=domain,dc=com
  uid=jdoe,ou=People,dc=domain,dc=com
    ou=Preferences,uid=jdoe,dc=domain,dc=com
      ou=firstpreference,ou=Preferences,uid=jdoe,dc=domain,dc=com
        value : 123
        value : 456

У меня есть несколько вопросов:

  1. Является ли jsut под пользовательской записью правильным местом для начала сохранения настроек? Каким objectClass должна быть эта запись? Я экспериментирую с организационной единицей, но она кажется неправильной.

  2. Каков наилучший способ сохранить пары имя-значение для предпочтений? Здесь мой лучший гость - создать запись под настройками, имеющими имя, и создать значение под ним. Таким образом, я могу учесть несколько значений. Каким должен быть правильный objectClass для этих записей?

Я работаю с OpenLDAP и не хотел бы менять схемы, которые идут с ним. Есть ли способ настроить это, используя доступные схемы?

Ответы [ 3 ]

2 голосов
/ 07 декабря 2009

  1. Вы, конечно, можете хранить настройки как дочерние элементы пользовательского узла. Альтернативы могут быть на самом пользовательском узле или в совершенно отдельной ветке. Зависит от того, как вы будете его поддерживать (у кого будут разрешения, насколько детализированы разрешения, как часто будут добавляться новые настройки и приложения и т. Д.).

    OU - неправильный тип объекта. Вы должны определить свою собственную схему в соответствии с вашим приложением. Как правило, вы хотите, чтобы изменения схемы были минимальными, поэтому определяемую вами схему следует разрабатывать так, чтобы она была расширяемой при необходимости новых предпочтений / приложений.

  2. Вы можете определить атрибут для каждого предпочтения и использовать встроенную поддержку пары имя-значение на сервере LDAP. Или вы можете определить общий атрибут «предпочтения» и сохранить имя и значение в данных. Опять же, от того, как вы это сделаете, зависит количество предпочтений, частота изменений, возможность поиска и индексирования полей и т. Д.

Ничто не мешает вам использовать встроенные типы для всего. Точно так же, как ничто не мешает вам вызывать все ваши переменные v1, v2 и ваши файлы stuff.txt. Но когда нет встроенных типов, соответствующих вашим потребностям, самое время добавить свои собственные. Это довольно простая вещь.

0 голосов
/ 18 мая 2015

Хотя LDAP является универсальной базой данных, оптимизированной для чтения, в отличие от SQL, оптимизированного для чтения / записи, а базы данных NoSQL db являются ключами-значениями. LDAP отлично подходит для крупномасштабного развертывания с учетом кластеризации, которая записывает один раз и читает много раз. Но сценарий использования, в котором для значений ключа предусмотрено много операций чтения / записи, а затем базы данных NoSQL, такой как redis или memcached, лучше использовать для баз данных с базовыми значениями ключей.

0 голосов
/ 12 октября 2009

Я не думаю, что каталог LDAP был бы лучшим местом для хранения этого, действительно. Если это настройки веб-приложения, вы должны хранить их вместе с ними и в веб-приложениях - совместно.

Каталог LDAP связан с вашими учетными записями пользователей, разрешениями, структурой вашей организации - я бы не рекомендовал помещать специфичные для приложения настройки в каталог LDAP.

Марк

...