You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by Norbet Reilly <nr...@gmail.com> on 2005/09/23 01:55:20 UTC

DIREVE-253

Hi Trustin,
 Just thought I might mention this issue to you as well, as I gather from
your postings that you are the MINA guru, and my limitted understanding of
the root cause under this issue leads me to suspect that the MINA level may
be involved in some way.
 I know you guys are really busy, but if you get a second to scan the issue
(and reassign the component if reqd) that would be great. I'm happy to
investigate further but don't really know how to go about it, so if there
are any simple pointers about how to investigate further I'll hop to it. For
instance I'm not sure why URL encoding gets into the LDAP results picture at
all, and where it might be occuring in the code.
 Thanks

Re: DIREVE-253

Posted by Jérôme Baumgarten <jb...@gmail.com>.
Iirc an LDAP URL is returned for an alias that falls outside of the
search base. In my LDAP proxy I treat alias in a way to return a DN
and not an LDAP URL because it seems to me unnecessary to return an
LDAP URL in that case and also to avoid the client bypassing the
proxy.

Jérôme

On 9/23/05, Marc Boorshtein <mb...@gmail.com> wrote:
> JNDI will return an LDAP URL as the name of an entry if it falls outside of
> the the search base (ie if a referral to another server was followed that
> uses a different namespace).
>
>  Marc
>
> On 9/23/05, Norbet Reilly <nr...@gmail.com> wrote:
> > No need to apologise ;-) and in fact that is what the dummy partition
> > I attached to the issue does (sends back hardcoded info). Another note
> > in the issue is that absolute entries seem to have URL style names,
> > which seems relevant ...
> >
> > Thanks
> >
>
>

Re: DIREVE-253

Posted by Marc Boorshtein <mb...@gmail.com>.
JNDI will return an LDAP URL as the name of an entry if it falls outside of
the the search base (ie if a referral to another server was followed that
uses a different namespace).

Marc

On 9/23/05, Norbet Reilly <nr...@gmail.com> wrote:
>
> No need to apologise ;-) and in fact that is what the dummy partition
> I attached to the issue does (sends back hardcoded info). Another note
> in the issue is that absolute entries seem to have URL style names,
> which seems relevant ...
>
> Thanks
>

Re: DIREVE-253

Posted by Norbet Reilly <nr...@gmail.com>.
No need to apologise ;-) and in fact that is what the dummy partition
I attached to the issue does (sends back hardcoded info). Another note
in the issue is that absolute entries seem to have URL style names,
which seems relevant ...

Thanks

Re: DIREVE-253

Posted by Alex Karasulu <ao...@bellsouth.net>.
Please excuse my asking instead of reading your submitted example for 
reproducing this bug.  Did you try mocking up the results returned from 
the proxied LDAP server?  Meaning have you tried making a mock 
implementation that does not use the SUN JNDI provider to get the result 
from the remote server but gives hard coded results?

My suspicion is that something might be going on within the SUN JNDI 
provider.  Either that or distinguished names are being handled like 
LDAP URLs instead.

Alex
 

Re: DIREVE-253

Posted by Trustin Lee <tr...@gmail.com>.
Hi Norbert,

2005/9/23, Norbet Reilly <nr...@gmail.com>:
>
> Hi Trustin,
>  Just thought I might mention this issue to you as well, as I gather from
> your postings that you are the MINA guru, and my limitted understanding of
> the root cause under this issue leads me to suspect that the MINA level may
> be involved in some way.
>

MINA is just a network application framework. It doesn't have relationship
with escaping IMHO. You'd better to look at the LDAP protocol handler and
LDAP codec. You can locate them at:

* protocol-providers\ldap\trunk
* shared\ldap\trunk

I know you guys are really busy, but if you get a second to scan the issue
> (and reassign the component if reqd) that would be great. I'm happy to
> investigate further but don't really know how to go about it, so if there
> are any simple pointers about how to investigate further I'll hop to it. For
> instance I'm not sure why URL encoding gets into the LDAP results picture at
> all, and where it might be occuring in the code.
>

I didn't look into the codec part, so I cannot tell you why URL encoding
gets into LDAP. Perhaps Alex or Emmanuel could help us here.

Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/