HI!
Maybe I'm overlooking something obvious...
I'd like to enforce a prefix naming convention by using a set-based constraint. The idea is that 'cn' value of an entry should *start* with the 'cn' value of the superior entry and a hyphen.
Example with Superior entry has 'cn: example': example-foo -> accept examplefoo -> disallow foo-bar -> disallow
My problem is the "start with" since I cannot find a way to express the wildcard string in a set.
The following does not work since [*] is interpreted literally so only the exact value 'example-*' is accepted:
# 'cn' has to use superior entry's 'cn' value as prefix constraint_attribute cn set "(this/-1/cn + [-] + [*] ) & this/cn"
restrict="ldap:///ou=ampua??sub?(|(objectClass=mySrvGroup)(objectClass=myGroup))"
Any help is appreciated.
Ciao, Michael.
On 02/03/2014 07:26 PM, Michael Ströder wrote:
HI!
Maybe I'm overlooking something obvious...
I'd like to enforce a prefix naming convention by using a set-based constraint. The idea is that 'cn' value of an entry should *start* with the 'cn' value of the superior entry and a hyphen.
Example with Superior entry has 'cn: example': example-foo -> accept examplefoo -> disallow foo-bar -> disallow
My problem is the "start with" since I cannot find a way to express the wildcard string in a set.
The following does not work since [*] is interpreted literally so only the exact value 'example-*' is accepted:
# 'cn' has to use superior entry's 'cn' value as prefix constraint_attribute cn set "(this/-1/cn + [-] + [*] ) & this/cn"
restrict="ldap:///ou=ampua??sub?(|(objectClass=mySrvGroup)(objectClass=myGroup))"
Any help is appreciated.
It is not possible, AFAIK. If you step back and consider how sets work, I don't see how such semantics could be applied. Each statement is applied to a value and transformed into a set of strings (hence the name "sets"). The resulting sets are further manipulated according to the statements until they cannot be further reduced. If the operation ends with an empty set, the result is "no"; otherwise, it is "yes".
In your case, "this/-1/cn" expands to the values of the "cn" attribute of the parent (i.e. a set of as many values as the number of "cn" values in the parent entry). Each of those values is added '-'; then, you want an arbitrary string to be added.
In order to be feasible, sets would need either of two possible extensions:
1) add a "regex" operator in addition to "&" (in this context, "&" means "exact match"); then one could use something like
"(this/-1/cn + [-] + [.*] ) regex this/cn"
where "regex" is the operator (a better syntax could be invented); note the "[.*]", as I'd recommend to use extended regex.
2) add a filter-like operator, such that
"(this/cn=(this/-1/cn + [-] + * ))"
is turned into
foreach left in { "this/cn[0]", "this/cn[1]" , ... } { foreach right in { "this/-1/cn" + "-" SUBFINAL } { SUBSTRING_MATCH(left, right) } }
Note that above '*' has no [], because now it is a special character, indicating that the expression it appears in will produce a (set of) string(s) that must be subjected to substrings match.
I believe approach (1) is a bit easier to implement than (2); it will likely make sets even less performing, but this is something sets users already must take into account.
p.
Hi,
Le 03/02/2014 19:26, Michael Ströder a écrit :
HI!
Maybe I'm overlooking something obvious...
I'd like to enforce a prefix naming convention by using a set-based constraint. The idea is that 'cn' value of an entry should *start* with the 'cn' value of the superior entry and a hyphen.
Example with Superior entry has 'cn: example': example-foo -> accept examplefoo -> disallow foo-bar -> disallow
My problem is the "start with" since I cannot find a way to express the wildcard string in a set.
I think the wildcard can be expressed in a filter. Some something like this should work (untested):
this & ( [ldap:///] + this/entryDn + [??base?(cn=] + this/-1/cn + [-*)] )
Regards, Raphaël Ouazana.
openldap-technical@openldap.org