Full_Name: Version: 2.4.39 OS: not relevant URL: Submission from: (NULL) (79.219.107.130) Not sure whether this is a regression caused by the fix for ITS#7773. Given this constraint: constraint_attribute uid count 1 restrict="ldap:///ou=example??sub?(objectClass=account)" One can still add two 'uid' values when sending an add request like this: dn: uid=test1,ou=example changetype: add objectClass: account uid: test2 [..] Generally I don't like this magic of accepting both attribute values from DN and entry. :-/
On 03/15/2014 05:38 PM, michael@stroeder.com wrote: > Full_Name: > Version: 2.4.39 > OS: not relevant > URL: > Submission from: (NULL) (79.219.107.130) > > > Not sure whether this is a regression caused by the fix for ITS#7773. > > Given this constraint: > > constraint_attribute > uid > count 1 > restrict="ldap:///ou=example??sub?(objectClass=account)" > > One can still add two 'uid' values when sending an add request like this: > > dn: uid=test1,ou=example > changetype: add > objectClass: account > uid: test2 > [..] > > Generally I don't like this magic of accepting both attribute values from DN and > entry. :-/ Indeed, the check (and magic) of adding distinguished value(s) to entry occurs during entry_naming_check(), which occurs during entry_schema_check(), which occurs in the backend add operations, right after overlays had a chance to look at the entry. 2 approaches: a) anticipate naming check b) duplicate naming check in slapo-constraint (b) is a waste, but "localized"; not sure what would be the side effects of (a). p. -- Pierangelo Masarati Associate Professor Dipartimento di Scienze e Tecnologie Aerospaziali Politecnico di Milano