HI!
Consider the following config for slapo-constraint in slapd.conf:
constraint_attribute ou uri ldap:///o=Test Company?ou?sub?(objectClass=organizationalUnit)
With this example the constrained attribute is the same like the one used in the LDAP URL. Now how are entries handled which are search results of the LDAP URL? In this example how to deal with new values of attribute 'ou' in case of adding a new entry with object class 'organizationalUnit'?
Ciao, Michael.
Michael Ströder wrote:
HI!
Consider the following config for slapo-constraint in slapd.conf:
constraint_attribute ou uri ldap:///o=Test Company?ou?sub?(objectClass=organizationalUnit)
With this example the constrained attribute is the same like the one used in the LDAP URL. Now how are entries handled which are search results of the LDAP URL? In this example how to deal with new values of attribute 'ou' in case of adding a new entry with object class 'organizationalUnit'?
I would expect the source data for the constraint to reside in a separate DIT, outside the constraint overlay's control.
Howard Chu wrote:
Michael Ströder wrote:
Consider the following config for slapo-constraint in slapd.conf:
constraint_attribute ou uri ldap:///o=Test Company?ou?sub?(objectClass=organizationalUnit)
With this example the constrained attribute is the same like the one used in the LDAP URL. Now how are entries handled which are search results of the LDAP URL? In this example how to deal with new values of attribute 'ou' in case of adding a new entry with object class 'organizationalUnit'?
I would expect the source data for the constraint to reside in a separate DIT, outside the constraint overlay's control.
IMO this would be a rather awkward requirement.
Ciao, Michael.
Michael Ströder wrote:
Howard Chu wrote:
Michael Ströder wrote:
Consider the following config for slapo-constraint in slapd.conf:
constraint_attribute ou uri ldap:///o=Test Company?ou?sub?(objectClass=organizationalUnit)
With this example the constrained attribute is the same like the one used in the LDAP URL. Now how are entries handled which are search results of the LDAP URL? In this example how to deal with new values of attribute 'ou' in case of adding a new entry with object class 'organizationalUnit'?
I would expect the source data for the constraint to reside in a separate DIT, outside the constraint overlay's control.
IMO this would be a rather awkward requirement.
IMO this would be a rather awkward configuration in the first place. Store the source data in some other attribute...
Michael Ströder wrote:
Howard Chu wrote:
Michael Ströder wrote:
Consider the following config for slapo-constraint in slapd.conf:
constraint_attribute ou uri ldap:///o=Test Company?ou?sub?(objectClass=organizationalUnit)
With this example the constrained attribute is the same like the one used in the LDAP URL. Now how are entries handled which are search results of the LDAP URL? In this example how to deal with new values of attribute 'ou' in case of adding a new entry with object class 'organizationalUnit'?
I would expect the source data for the constraint to reside in a separate DIT, outside the constraint overlay's control.
IMO this would be a rather awkward requirement.
Let me restate: If "reside in a separate DIT" means a separate database this would be an awkward requirement.
I'd rather like to see another parameter which controls for which entries the constraints are enforced applicable within the same database. Similar to parameters unique_uri and/or unique_base of slapo-unique.
Ciao, Michael.
Michael Ströder wrote:
Let me restate: If "reside in a separate DIT" means a separate database this would be an awkward requirement.
I'd rather like to see another parameter which controls for which entries the constraints are enforced applicable within the same database. Similar to parameters unique_uri and/or unique_base of slapo-unique.
Indeed, that could be useful. It would probably be useful for several of the overlays.
It would be even more useful to have a generic config feature for this purpose, so that it doesn't need to be explicitly coded for each overlay. The most logical approach would be to implement subentry support, and tie their subtree search specifications into these functions. You're welcome to submit a patch with this implementation.
Howard Chu wrote:
Michael Ströder wrote:
Howard Chu wrote:
Michael Ströder wrote:
Consider the following config for slapo-constraint in slapd.conf:
constraint_attribute ou uri ldap:///o=Test Company?ou?sub?(objectClass=organizationalUnit)
With this example the constrained attribute is the same like the one used in the LDAP URL. Now how are entries handled which are search results of the LDAP URL? In this example how to deal with new values of attribute 'ou' in case of adding a new entry with object class 'organizationalUnit'?
I would expect the source data for the constraint to reside in a separate DIT, outside the constraint overlay's control.
IMO this would be a rather awkward requirement.
IMO this would be a rather awkward configuration in the first place. Store the source data in some other attribute...
I guess to most people it seems quite natural to store it in the same attribute. So you can e.g. define departmentNumber in a user entry contains the very same value like the attribute departmentNumber of the related department entry.
Ciao, Michael.
-
Howard Chu -
Michael Ströder