Helo
Is the kind of ACL below supported? access to dn.regex="^uid=.+,(ou=.+),o=org$" attrs=foo val.regex="^(.*)$" by ...
I expect $1 to hold ou=whatever and $2 to hold attribute foo value that gets modified. I have trouble to get it working, and I wonder if 1) are $<digit> supported in val.regex ? 2) is it allowed touse $<digit> with multiples regex? Ot will the values gathered by the last match overwrite the first one?
Emmanuel Dreyfus wrote:
Helo
Is the kind of ACL below supported? access to dn.regex="^uid=.+,(ou=.+),o=org$" attrs=foo val.regex="^(.*)$" by ...
I expect $1 to hold ou=whatever and $2 to hold attribute foo value that gets modified. I have trouble to get it working, and I wonder if
- are $<digit> supported in val.regex ?
No, AFAIK.
- is it allowed touse $<digit> with multiples regex? Ot will the values
gathered by the last match overwrite the first one?
You should define its meaning. If val.regex were to support submatches, I don't see anything preventing slapd from considering the various bits of the <what> part as a single, ordered source of submatches to be used in the <by> clause. You should be aware, however, that the ordering of <what> (and <by>) patterns is hardcoded, and they get re-sorted internally. For example, you could write
access to dn.regex="^uid=.+,(ou=.+),o=org$" attrs=foo val.regex="^(.*)$"
or
access to attrs=foo val.regex="^(.*)$" dn.regex="^uid=.+,(ou=.+),o=org$"
and they would be represented exactly the same in the ACL data structure. As such, determining what's $1 and what's $2 would need to be predefined, and not based on how you typed it in your rule.
p.
Ing. Pierangelo Masarati OpenLDAP Core Team
SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando@sys-net.it -----------------------------------
Pierangelo Masarati ando@sys-net.it wrote:
- are $<digit> supported in val.regex ?
No, AFAIK.
I implemented ${v<digit>+} for substituing from val.regex. It took some time because the modification ended to be much more extensive than expected.
Please reveiw ITS#5804 and tell me if it looks safe to commit.
openldap-software@openldap.org