ando@sys-net.it wrote:
michael@stroeder.com wrote:
ando@sys-net.it wrote:
Hallvard B Furuseth wrote:
ando@sys-net.it writes:
On a related note, if this can be considered of general usefulness, LDAP specs would need to be changed in order to define a finer grain of attribute request; something like:
empty or "*" ; all user, except attrs that need to be explicitly req. "+" ; all operational
<all including attrs that need to be explicitly requested> <...>
Would it be cleaner if slapo-cloak redefines the attributes to be operational, or to behave as if they are? Maybe give them an X-AS-OPERATIONAL extension? Or would that just mess up schema code, things like attribute inheritance?
I think things would mess up.
I'd also recommend *not* to turn user attribute types into operational attribute types. This would certainly confuse schema-aware clients.
Moreover, I see a number of features system administrators could ask for; e.g. hide attributes only when matching a URI (base, scope, filter),
Well, that's something many overlays would benefit from.
In fact, based on recent modifications to slapo-constraint(5) and other overlays, I'm considering the opportunity to introduce generic helpers to parse and check this type of generic limitations.
We've discussed this before - overlays ought to have a configurable range of effect, using an X.500 Subtree Search Specification.