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

[Daniel <deepee@gmx.net>]

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
> > > > that
> > > > checks how a given value compares with "now"; something like
> > > > "greaterThanNow" and "lessThanNow".  This would allow to do something
> > > > like
> > > >
> > > > access to attrs=validnow val/greaterThanNow=19700101000000Z
> > > >
> > > > or
> > > >
> > > > 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
> > they?
> >     
> 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
> > box)
> >     
> That makes sense, although it would be orthogonal to using the
> earlierThanNow/laterThanNow rules through extensible filters.
>   
ok.
> > 2. use the two additional MRs on-demand (replacing the above "default"
> > ORDERING by the new ones), e.g.:
> >      (validNotBefore:earlierThanNow:<epoch) or/and
> > (validNotBefore:earlierThanNow:>epoch)
> >     
> 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.