如何在 ldap 目录中存储简单的名称值对
我正在为一系列共享相同用户的 Web 应用程序创建一个用户存储库 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
我有几个问题：
用户条目下方的位置是开始存储首选项的正确位置吗？该条目应该是什么对象类？我正在尝试使用organizationalUnit，但它似乎不正确。
存储首选项的名称值对的最佳方式是什么？在这里，我最好的客人是在具有名称的首选项下方创建一个条目，并在其下方创建值。这样我就可以考虑多个值。这些条目的正确 objectClass 应该是什么？
我正在使用 OpenLDAP，并且不想更改它附带的模式。有没有办法使用可用的模式来设置它？
I'm creating a user repository ldap backend for a series of web applications sharing the same users. I would like to store preference information in this ldap location. This way everything related to users is maintained in the same place and can be shared among all applications.
I'm thinking of a general structure like this:
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
I have several questions:
Is jsut below the user entry the right place to start storing the preferences? What objectClass should this entry be? I'm experimenting with organizationalUnit but it doesn't seem right.
What is the best way to store name value pairs for the preferences? Here my best guest is to create an entry just below the preferences having a name and create the value just under it. This way I can account for multiple values. What should be the correct objectClass for those entries?
I'm working with OpenLDAP and wouldn't like to change the schemas that come with it. Is there a way to set this up using available schemas?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
您当然可以将首选项存储为用户节点的子节点。替代方案可以在用户节点本身或完全独立的分支中。取决于您将如何维护它（谁将拥有权限、权限的粒度、添加新首选项和应用程序的频率等）。
OU 是错误的对象类型。您应该定义自己的架构以适合您的应用程序。通常，您希望将架构更改保持在最低限度，因此您定义的架构应设计为在需要新首选项/应用程序时可扩展。
您可以为每个首选项定义一个属性并使用 LDAP 服务器的内置名称/值对支持。或者，您可以定义通用“首选项”属性并将名称和值存储在数据中。同样，您如何做到这一点取决于有多少首选项、更改频率、搜索和索引字段的能力等。
没有什么可以阻止您对所有内容使用内置类型。就像没有什么可以阻止您调用所有变量 v1、v2 和文件 stuff.txt 一样。但是，当没有任何内置类型满足您的需求时，就需要添加您自己的类型了。这是一件非常简单的事情。
You can certainly store preferences as children of the user node. Alternatives would be on the user node itself or in a completely separate branch. Depends on how you will be maintaining it (who will have permissions, how granular the permissions are, how often new preferences and applications will be added, etc).
OU is the wrong object type. You should define your own schema to suit your application. Generally you want to keep schema changes to a minimum, so the schema you define should be designed to be extensible when new preferences / apps are needed.
You can either define an attribute for each preference and use the LDAP server's inbuilt name-value pair support. Or you can define a generic 'preferences' attribute and store the name and value in the data. Again, how you do it depends how many preferences there are, frequency of changes, ability to search and index fields, etc.
There's nothing to stop you using inbuilt types for everything. Just like there is nothing to stop you calling all your variables v1, v2 and your files stuff.txt. But when there aren't any inbuilt types that match your needs, this is the time to add your own. It's a pretty simple thing to do.
我确实认为 LDAP 目录不是存储此内容的最佳位置。如果是 Web 应用程序首选项，您应该将它们与 Web 应用程序一起存储并存储在 Web 应用程序中 - 以共享的方式。
LDAP 目录与您的用户帐户、权限、组织结构有关 - 我不建议将特定于应用程序的设置放入 LDAP 目录中。
马克
I don't think the LDAP directory would be the best place to store this, really. If it's web application preferences, you should store them with and in the web applications - in a shared fashion.
The LDAP directory is concerned with your user accounts, permissions, your organization's structure - I would not recommend putting application-specific settings inside the LDAP directory.
Marc
LDAP 是一种多功能的读优化数据库，而 SQL 是读/写优化的，而 NoSQL 数据库是键值数据存储。 LDAP 非常适合大规模部署，并且已经考虑到一次写入和多次读取的集群。但是，如果用例对键值有很多读/写操作，那么像 Redis 或 Memcached 这样的 NoSQL 数据库更适合基本键值数据存储。
While LDAP is a versiatile read optimized database as appose to SQL being read/write optimized and NoSQL db's being key-value datastores. LDAP is great for large scale deployment with clustering already in mind that writes once and reads many times. But a use case that has many read/writes for key values then a NoSQL database like redis or memcached is better for basic key value datastores.