[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: (ITS#5760) attribute hiding in rwm overlay
--0016e648d4747104c80462dfbb05
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
On Sat, Feb 14, 2009 at 7:40 PM, Pierangelo Masarati <ando@sys-net.it>wrote:
> brett.maxfield@gmail.com wrote:
>
>> --0016e65206024a6d9d0462d5c0d0
>> Content-Type: text/plain; charset=ISO-8859-1
>> Content-Transfer-Encoding: 7bit
>>
>> I have re-tested with recent RE24 and this still happens.
>>
>> Assuming the config (database meta, and map instead of rwm-map shows
>> similar
>> problem) :
>>
>> database ldap
>> suffix "c=AU"
>> uri "ldap://127.0.0.1:390/c=AU";
>>
>
> You messed things up a little bit: back-ldap does not allow the DN part of
> the URI.
>
Yes, sorry i was originally using meta backend & switched to ldap. Although
openldap seems to accept the DN component, but happily ignore it.
overlay rwm
>
> rwm-map attribute cn *
> rwm-map attribute sn *
> rwm-map attribute givenName *
> rwm-map attribute *
>
> rwm-map objectclass inetOrgPerson *
> rwm-map objectclass organisationalUnit *
>
s/organisationalUnit/organizationalUnit/: this raises a warning.
Ditto with the typing error.
Here the correct spelling is "organisation", i forgot to type it "wrong" for
openldap :P
Probably * and + (or *,+) should be expanded to the list of user or
> administrative attributes (respectively) by meta/rwm first, specifically
> those that are allowed by "map attribute" lines, before being handed to the
> real directory (helpful to performance if the backend directory has many
> attributes, that the meta directory is not interested in).
>
> This is also why attributes don't appear in a GUI browser for me, if i am
> using a GUI browser, as they commonly use *,+ as their default.
>
Well, if you don't request any attribute, those that are mapped appear.
> I've modified slapo-rwm to pass thru special attribute names ("*", "+",
> "1.1") in order to defer their mapping when results are returned. This looks
> simpler than detecting whether non-mapped attrs are filtered and, in tat
> case, replace "*" by the mapped attributes, although the latter could be an
> optimization.
>
> A fix is in HEAD (affecting back-meta and slapo-rwm independently). Please
> test. Unfortunately it seems to be too late for OpenLDAP 2.4.14.
>
Just tried, the fix works perfectly with database meta, overlay rwm, and
rwm-map :
database ldap
suffix "c=AU"
uri "ldap://127.0.0.1 <http://127.0.0.1:390/c=AU>:390/c=AU"
overlay rwm
rwm-map attribute cn *
rwm-map attribute sn *
rwm-map attribute givenName *
rwm-map attribute createTimestamp *
rwm-map attribute modifyTimestamp *
rwm-map attribute *
rwm-map objectclass inetOrgPerson *
rwm-map objectclass organizationalUnit *
rwm-map objectclass organization *
rwm-map objectclass country *
rwm-map objectclass *
Eg :
ldapsearch -H ldap://127.0.0.1 <http://127.0.0.1:390/c=AU>:391 -x -b
'cn=test00496,ou=support,o=openldap,c=AU' '(objectclass=*)' '*' '+'
# extended LDIF
#
# LDAPv3
# base <cn=test00496,ou=support,o=openldap,c=AU> with scope subtree
# filter: (objectclass=*)
# requesting: * +
#
# test00496, support, openldap, AU
dn: cn=test00496,ou=support,o=openldap,c=AU
objectClass: inetOrgPerson
cn: test00496
givenName: test00496
sn: test00496lname
createTimestamp: 20090213130450Z
modifyTimestamp: 20090213130450Z
# search result
search: 2
result: 0 Success
# numResponses: 2
# numEntries: 1
However, there is also a similar problem with database meta, and map :
database meta
suffix "c=AU"
uri "ldap://127.0.0.1 <http://127.0.0.1:390/c=AU>:390/c=AU"
map attribute cn *
map attribute sn *
map attribute givenName *
map attribute *
map objectclass inetOrgPerson *
map objectclass organizationalUnit *
map objectclass organization *
map objectclass country *
map objectclass *
When i run the above i get :
ldapsearch -H ldap://127.0.0.1 <http://127.0.0.1:390/c=AU>:391 -x -b
'cn=test00496,ou=support,o=openldap,c=AU' '(objectclass=*)' '*' '+'
# extended LDIF
#
# LDAPv3
# base <cn=test00496,ou=support,o=openldap,c=AU> with scope subtree
# filter: (objectclass=*)
# requesting: * +
#
# test00496, support, openldap, AU
dn: cn=test00496,ou=support,o=openldap,c=AU
entryDN: cn=test00496,ou=support,o=openldap,c=AU
subschemaSubentry: cn=Subschema
# search result
search: 2
result: 0 Success
# numResponses: 2
# numEntries: 1
Which is not (yet) showing the user attributes, and is leaking some
un-requested operational attributes.
Cheers
Brett
--0016e648d4747104c80462dfbb05
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div class=3D"gmail_quote">On Sat, Feb 14, 2009 at 7:40 PM, Pierangelo Masa=
rati <span dir=3D"ltr"><<a href=3D"mailto:ando@sys-net.it"; target=3D"_bl=
ank">ando@sys-net.it</a>></span> wrote:<br><blockquote class=3D"gmail_qu=
ote" style=3D"border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0p=
t 0.8ex; padding-left: 1ex;">
<div><a href=3D"mailto:brett.maxfield@gmail.com"; target=3D"_blank">brett.ma=
xfield@gmail.com</a> wrote:<br>
</div><blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid rgb=
(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
--0016e65206024a6d9d0462d5c0d0<br>
Content-Type: text/plain; charset=3DISO-8859-1<br>
Content-Transfer-Encoding: 7bit<div><br>
<br>
I have re-tested with recent RE24 and this still happens.<br>
<br>
Assuming the config (database meta, and map instead of rwm-map shows simila=
r<br>
problem) :<br>
<br>
database ldap<br>
suffix "c=3DAU"<br>
uri "ldap://<a href=3D"http:=
//127.0.0.1:390/c=3DAU" target=3D"_blank">127.0.0.1:390/c=3DAU</a>"<br=
>
</div></blockquote>
<br>
You messed things up a little bit: back-ldap does not allow the DN part of =
the URI.<div></div></blockquote><div><br>Yes, sorry i was originally using =
meta backend & switched to ldap. Although openldap seems to accept the =
DN component, but happily ignore it.<br>
<br>
<blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid rgb(204, =
204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
overlay rwm<br>
<br>
rwm-map attribute cn *<br>
rwm-map attribute sn *<br>
rwm-map attribute givenName *<br>
rwm-map attribute *<br>
<br>
rwm-map objectclass inetOrgPerson *<br>
rwm-map objectclass organisationalUnit *<br>
</blockquote>
<br></div><blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid=
rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
s/organisationalUnit/organizationalUnit/: this raises a warning.</blockquot=
e><div><br>Ditto with the typing error.<br><br>Here the correct spelling is=
"organisation", i forgot to type it "wrong" for openld=
ap :P<br>
<br><blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid rgb(2=
04, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Probably * an=
d + (or *,+) should be expanded to the list of user or<br>
administrative attributes (respectively) by meta/rwm first, specifically<br=
>
those that are allowed by "map attribute" lines, before being han=
ded to the<br>
real directory (helpful to performance if the backend directory has many<br=
>
attributes, that the meta directory is not interested in).<br>
<br>
This is also why attributes don't appear in a GUI browser for me, if i =
am<br>
using a GUI browser, as they commonly use *,+ as their default.<br>
</blockquote>
<br></div><blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid=
rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Well, if you don't request any attribute, those that are mapped appear.=
I've modified slapo-rwm to pass thru special attribute names (&q=
uot;*", "+", "1.1") in order to defer their mappin=
g when results are returned. This looks simpler than detecting whether non-=
mapped attrs are filtered and, in tat case, replace "*" by the ma=
pped attributes, although the latter could be an optimization.<br>
<br>
A fix is in HEAD (affecting back-meta and slapo-rwm independently). Please =
test. Unfortunately it seems to be too late for OpenLDAP 2.4.14.<div>=
</div></blockquote><div><br>Just tried, the fix works perfectly with databa=
se meta, overlay rwm, and rwm-map :<br>
<br>database ldap<br>suffix =
"c=3DAU"<br>uri &=
nbsp; "lda=
p://<a href=3D"http://127.0.0.1:390/c=3DAU"; target=3D"_blank">127.0.0.1</a>=
:390/c=3DAU"<br><br>overlay rwm<br><br>rwm-map attribute cn *<br>
rwm-map attribute sn *<br>rwm-map attribute givenName *<br>rwm-map attribut=
e createTimestamp *<br>rwm-map attribute modifyTimestamp *<br>rwm-map attri=
bute *<br><br>rwm-map objectclass inetOrgPerson *<br>rwm-map objectclass or=
ganizationalUnit *<br>
rwm-map objectclass organization *<br>rwm-map objectclass country *<br>rwm-=
map objectclass *<br><br>Eg :<br><br>ldapsearch -H ldap://<a href=3D"http:/=
/127.0.0.1:390/c=3DAU" target=3D"_blank">127.0.0.1</a>:391 -x -b 'cn=3D=
test00496,ou=3Dsupport,o=3Dopenldap,c=3DAU' '(objectclass=3D*)'=
'*' '+'<br>
# extended LDIF<br>#<br># LDAPv3<br># base <cn=3Dtest00496,ou=3Dsupport,=
o=3Dopenldap,c=3DAU> with scope subtree<br># filter: (objectclass=3D*)<b=
r># requesting: * +<br>#<br><br># test00496, support, openldap, AU<br>dn: c=
n=3Dtest00496,ou=3Dsupport,o=3Dopenldap,c=3DAU<br>
objectClass: inetOrgPerson<br>cn: test00496<br>givenName: test00496<br>sn: =
test00496lname<br>createTimestamp: 20090213130450Z<br>modifyTimestamp: 2009=
0213130450Z<br><br># search result<br>search: 2<br>result: 0 Success<br>
<br># numResponses: 2<br># numEntries: 1<br><br></div></div>However, there =
is also a similar problem with database meta, and map :<br><br>database&nbs=
p; meta<br>suffix &nbs=
p; "c=3DAU"<br>uri  =
; "ldap://<a hre=
f=3D"http://127.0.0.1:390/c=3DAU"; target=3D"_blank">127.0.0.1</a>:390/c=3DA=
U"<br>
<br>map attribute cn *<br>map attribute sn *<br>map attribute givenName *<b=
r>map attribute *<br><br>map objectclass inetOrgPerson *<br>map objectclass=
organizationalUnit *<br>map objectclass organization *<br>map objectclass =
country *<br>
map objectclass *<br><br>When i run the above i get :<br><br>ldapsearch -H =
ldap://<a href=3D"http://127.0.0.1:390/c=3DAU"; target=3D"_blank">127.0.0.1<=
/a>:391 -x -b 'cn=3Dtest00496,ou=3Dsupport,o=3Dopenldap,c=3DAU' =
9;(objectclass=3D*)' '*' '+'<br>
# extended LDIF<br>#<br># LDAPv3<br># base <cn=3Dtest00496,ou=3Dsupport,=
o=3Dopenldap,c=3DAU> with scope subtree<br># filter: (objectclass=3D*)<b=
r># requesting: * +<br>#<br><br># test00496, support, openldap, AU<br>dn: c=
n=3Dtest00496,ou=3Dsupport,o=3Dopenldap,c=3DAU<br>
entryDN: cn=3Dtest00496,ou=3Dsupport,o=3Dopenldap,c=3DAU<br>subschemaSubent=
ry: cn=3DSubschema<br><br># search result<br>search: 2<br>result: 0 Success=
<br><br># numResponses: 2<br># numEntries: 1<br><br>Which is not (yet) show=
ing the user attributes, and is leaking some un-requested operational attri=
butes.<br>
<br>Cheers<br>Brett<br>
--0016e648d4747104c80462dfbb05--