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.
The attr "validnow" does not really exist. It's used for "detection" purposes only (that's the kind of protocol violation I've talked about).
The effective (exploded) filter contains the entries validity period's dead-ends (both generalizedTime Syntax): "validNotBefore" and "validNotAfter" which might be exist in an entry.
Nevertheless, I think I've understood your suggestion. I'll investigate into the direction of two additional MRs and try to implement them:
earlierThanNow and laterThanNow
This would result in a filter statement like this: (&(validNotBefore:earlierThanNow:=epoch)(validNotAfter:laterThanNow:=epoch))
Sounds this correct?
Thanks a lot!
Or, I'd write a dynacl module that does the same. I actually wrote one some time ago, and never found it useful. It's here ftp://ftp.openldap.org/incoming/pierangelo-masarati-2009-08-05.1.c
I have already had a look into contrib/slapd-modules/acl and decided: dynacl in general is not what I think I'll need or want. The ACL-processing would have been only a "nice to have". The core functionality is the server side transparent enforcment in combination with the bypass-exception. I have understood the dynacl contrib code the way, that only "by" clauses could be handled...