[Date Prev][Date Next]
suffix massaging in back-ldap (ITS#1002)
Full_Name: Pierangelo Masarati
Submission from: (NULL) (126.96.36.199)
There is a limitation in the suffix massaging feature recently introduced
in the devel branch of back-ldap (ITS#924).
The massaging is based on case-insensitive comparison of the terminal part of
incoming (all operations with a dn/base) and outgoing (search results) dns
the virtual and the real naming context strings as entered in slapd.conf with
the suffixmassage directive. A problem occurs in case the incoming/outgoing dn
has different "beautification" in terms of spaces after commas. As an example,
if the server is configured as
# "virtual naming context" for backend selection
# "virtual naming context" vs. "real naming context"
suffixmassage "dc=my,dc=org" "o=My Org, c=IT"
a request with, for instance, a search base of "dc=my, dc=org" would correctly
make the database be selected, because the suffix comparison is made against
NORMALIZED dn. However, as the suffix massage comparison needs be performed
against the non-normalized dns, no massaging would occur, resulting in a failed
search and in any case in a behavior that is different from the desired one.
This limitation would be overcome by splitting the suffix comparison into the
comparison of each relative dn component; otherwise, the comparison could be
against the normalized strings, whereas the correct splitting point needs be
recovered in an alternative manner, that does not rely on the length of the
matching part ...
All these problems would be overcome by the rewriting capability proposed in
ITS#989, by using the following syntax:
# all client->server rewrite operations
rewriteRule "(.*)dc=my,([ ]?)dc=org" "%1o=My Org,%2c=IT"
# only server->client rewrite operation
rewriteRule "(.*)o=My Org,([ ]?)c=IT" "%1dc=my,%2dc=org"
# no rewriting of search filters (no rewriteRule directive should follow...)
Pierangelo Masarati mailto:email@example.com
Developer, SysNet s.n.c. http://www.sys-net.it