[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: slapd/acl.c: using "filter=()" in an acl does not trigger an overlay's search callback

masarati@aero.polimi.it schrieb:
Daniel schrieb:
masarati@aero.polimi.it schrieb:
What kind of alternative solutions exist or do you see?
I'd rather define a new ordering matching rule for time-valued attrs
checks how a given value compares with "now"; something like
"greaterThanNow" and "lessThanNow".  This would allow to do something

access to attrs=validnow val/greaterThanNow=19700101000000Z


access to filter=(validnow:greaterThanNow:=19700101000000Z)

where 19700101000000Z (the epoch) is used as a placeholder for the
asserted value, which would be ignored.
After some experiments with MRs I think that I have not understood your
suggestion the right way or your suggestion is misleading...

In case the two new MRs "earlierThanNow" and "laterThanNow" are new
ORDERING MRs they have to be compared using lt- or gt-operators, haven't
No, you need to use an extensible filter, which is sort of a generalized
assertion.  What you use is "attr:mr:=value".  Then, it's the purpose of
"mr", your custom matching rule, to perform something that is equivalent
to an ordering match.  Your attributes do not need to have anything
special about matching rules.  They could even have no matching rule
defined.  All they need is to have "generalizedTime" syntax, so that your
custom matching rule can be applied.
That was a very helpful explanation - thanks a lot!

 From the results of my MR-tests I think I should/could:
1. define ORDERING using "generalizedTimeOrderingMatch" (to make
standard LE/GE ldapsearch filtering using "<=" and ">=" work out of the
That makes sense, although it would be orthogonal to using the
earlierThanNow/laterThanNow rules through extensible filters.
2. use the two additional MRs on-demand (replacing the above "default"
ORDERING by the new ones), e.g.:
     (validNotBefore:earlierThanNow:<epoch) or/and
The above string representations do not conform to LDAP search filters. See RFC 4515 for a definition of extensible match.
Ahhh I see, the "ordering matching rule" has led me into the completely wrong direction. Now it's clear. Thank again.