[Date Prev][Date Next]
Re: 2.3.1alpha and ACL set matching
> Pierangelo Masarati writes:
>> The point is that we don't know the attribute type of literals, and sets
>> are intended to match etherogeneous strings as well, as far as they
>> resolve to some string representation.
> Does this imply that sets do remember the attribute types of values
> fetched from the directory?
They don't (but they could); however, literals are not typed, so there's
little to remember.
>> I guess case-insensitive match might be a good trade-off, although
>> case-sensitive match might be desirable in few cases...
> I expect case-insensitive is the best choice. I don't think I've ever
> needed to know whether normalized values are uppercase or lowercase.
> One must use the normalized value with dn.regex too, except that IIRC
> that is case-insensitive.
regexes are case-insensitive, so the parallel with sets sounds reasonable.
I won't object making the comparison case-insensitive, at the price of
dropping the possibility of case-exact matches.
> Still, one could have a <set>.normalize(attributeType) operation
> if or when someone needs to match a case-sensitive attribute.
That would be advisable for dynamically generated literals (e.g. from
regex substitutions); however, for static portions, I'd live with
delegating normalization to the administrator (because a few lookups and
typings are worth avoiding the penalty of normalizing static strings at
every access checking). I note that the "." notation you use was the
original notation used for dereferencing an attribute; it was dropped in
favor of "/" (or the undocumented "->") because dots can appear inside an
OID, so "[<dn>].member.uid could be confusing if used as
I guess we need to define a way to call attributeType-specific methods
either implicitly or explicitly, i.e.
to normalize (or any other method) the result of the "attributeType"
dereferentiation from "set" according to the syntax of "attributeType", or
to apply normalization (or whatever) to "set" according to "syntax" rules.
With this mechanism, we could implement the escape/unescape rules you
were talking about in a related message:
"[cn=] + distinguishedName->escape(user/cn) + [,o=foo]"
"self/uid & distinguishedName->unescape([$1])"
In this case, the methods could be "normalize", "escape", "unescape"; more
could be added as required ("pretty"?).
> BTW, this reminds me: we ought to document what the normalized form of
> the various attribute types are, and maybe make a tool which normalizes
> input values according to a specified attribute type.
That would need to be a slap tool because it needs be schema-aware. some
SysNet - via Dossi,8 27100 Pavia Tel: +390382573859 Fax: +390382476497