I just tested it, and the fix seems to work well.  At first I thought
that your null check would actually cause a problem, in case the
exception is something besides a connection(or socket) closed, and the
provider chose to not to set the message on the exception.  But, I think
the fact that the retry is wrapped in yet another try catch block means
that life will probably go on.  I've been doing all sorts of fun weird
things to my LDAP server to try to get other types of exceptions thrown,
and it behaves as I would expect with your fix.

With defect 20518 -- It does seem innocent, though if the primary LDAP
server is down for an extended period of time, you would constantly be
trying it first, then the alternate.  But, I'm guessing the performance
hit is not huge and the fix seems correct beyond that.  (IE, to assume
the primary is forever gone is a bad idea and it is better to take the
potential performance hit).

You closed the bug regarding the userSubtree not working I see.  I'm
not sure but that there are still issues there, and I'm still
investigating.  I can get it to work if I add the [Public] object as a
trustee to any subcontext that I want searched, but this is by no means
a standard thing to do since it opens up your user containers to
potential security exploits.  Most of the exploits involve social
engineering; with public access to the names of the users in the
container, you can impersonate a user whose name you see and call up and
ask a help desk technician to change their password for you.  What I'm
not sure about is if there is some other acceptable way to grant browse
rights to some other object and then have Tomcat go in as that object. 
If so, then that would need to be documented if it is not already.  If
that is not possible, then the userSubtree feature is fairly useless
since most directory administrators would not take the security risk to
make it work.  Also, there are other bugs with this feature like the
fact that the first level is not searched for users, ONLY the sublevels

I emailed marek about the CLIENT-CERT problem, still no response.  I'm
going to look into it and see what the gist of Mario's objections were,
and if the patch is good.  
I know nothing about the iPlanet issue (except for what is in the bug
report), so that will be great if you have a fix...

Thanks Tim for working on these issues.

Jeff Tulley  ([EMAIL PROTECTED])
Novell, Inc., The Leading Provider of Net Business Solutions

>>> [EMAIL PROTECTED] 8/5/03 11:42:43 AM >>>
I got eager and saw you bug update yesterday and applied a patch to 4.1
night. Here's a link to the PATCH email:


The commit also does a null pointer check on the getMessage() to fix a

related bug and also avoids doing the toString().

As for bug 20518 - did this seem right? It seemed like an innocent fix.
they are the ones that seem to cause the most trouble)

IIRC, the only two bugs left I know of is:
1) The CLIENT-CERT one which I wish not to do but rather leave to
someone to 
Extend JNDIRealm. (But if someone else wants to commit it - I won't
2) Enhancement request for IPlanet since in a non-user binding the SHA1
isn't compatible with the way tomcat generates a hash. I have a patch
on my 
own from another project that might fix this. (If I can find the code)

AFAIK - All other JNDIRealm bugs are fixed or enhancements. If you can
from 4.1 and give me the OK - I can port the patch to 5. (I know I
in the wrong order :( ,  but did it on the hope that the patch had a
chance of being tested)


To unsubscribe, e-mail: [EMAIL PROTECTED] 
For additional commands, e-mail: [EMAIL PROTECTED] 

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to