When performing an LDAP connection via JavaScript, the LDAP30.JAR asks
for remote network access confirmation, and then proceeds to connect and
query the LDAP server.
When performing the same sequence of events with the LDAP40.JAR, it asks
for a remote network connection and THEN asks for a "local system"
access request ("reading files in your computer ... such as username
..."). This is never required when using LDAP30.JAR.
Even if a temporary GRANT is given to this system access request, the
LDAP process fails: a socket is opened with the remote LDAP server, but
the JavaScript fails with a Java exception: netscape/ldap/LDAPExeception
("unable to establish connection").
Substituting LDAP30.JAR in place of LDAP40.JAR, even on different Unix
platforms, allows these JavaScript-LDAP applications to work.
No amount of "signing" the JavaScript applications or re-signing the JAR
files with local certificates prevents the LDAP40.JAR behaviour and
problem. The same holds true for removing the user Netscape directory
and allowing NS to rebuild it. Even removing LDAP (security) ACL's has
no affect.
Is there a "trojan horse" in LDAP40.JAR?
What is the "problem" with LDAP40.JAR?