As a partial fix to http://bugzilla.ecoinformatics.org/show_bug.cgi?id=2747, I've modified AuthLdap.getGroups() and removed the code that handles LDAP referral connect and search timeout issues in a separate thread. I've replaced this code with ReferralException code that uses two JNDI parameter settings:
SearchControls.setTimeLimit() and com.sun.jndi.ldap.connect.timeout. The former limits how long in milliseconds a search can run without returning, and the latter limits how long in milliseconds a connection to an LDAP referral can wait with no successful connection. The previous code opened a new Thread for each ReferralException, and interrupted the thread after 5 seconds. In this way, the code is simpler and configurable.
Next, this patch changes how referrals are handled. Previously, the code would terminate and return the groups array after hitting any NamingException along the way. The new code iterates through all of the referrals in an outer loop, handling NamingExceptions within an inner try/catch statement. Once all referrals are processed, the groups array is finally returned.
Lastly, this patch changes how referred group hits are handled. This should be open for discussion and testing. As it is, groups that are found at the top level of the ecoinformatics.org LDAP tree will be returned as a relative group name, such as cn=marine. However, any referral group hits get returned as absolute URLs such as ldap://directory.piscoweb.org:389/cn=data-managers,ou=groups,dc=piscoweb,dc=org??sub. The above URL needs to be translated into an ecoinformatics.org-relative group. Therefore, this patch does a second query to the ecoinformatics LDAP and finds the point of the referral, in this case o=PISCOGROUPS,dc=ecoinformatics,dc=org. The group is then rebuilt as cn=data-managers,o=PISCOGROUPS,dc=ecoinformatics,dc=org.
The question arises: Is this a good convention to stick to? It assumes (as other parts of the Metacat code does) that groups are defined by commonName (cn) attributes, and are located just below the top level of the referral point. Perhaps there is a more flexible way to implement groups, but this way follows the conventions thus far in the NCEAS, PISCO, LTER, and UCNRS LDAP servers.
As a partial fix to http://bugzilla.ecoinformatics.org/show_bug.cgi?id=2747,
I've modified AuthLdap.getGroups() and removed the code that handles LDAP
referral connect and search timeout issues in a separate thread. I've replaced
this code with ReferralException code that uses two JNDI parameter settings:
SearchControls.setTimeLimit() and com.sun.jndi.ldap.connect.timeout. The former
limits how long in milliseconds a search can run without returning, and the
latter limits how long in milliseconds a connection to an LDAP referral can
wait with no successful connection. The previous code opened a new Thread
for each ReferralException, and interrupted the thread after 5 seconds. In
this way, the code is simpler and configurable.
Next, this patch changes how referrals are handled. Previously, the code
would terminate and return the groups array after hitting any NamingException
along the way. The new code iterates through all of the referrals in an outer
loop, handling NamingExceptions within an inner try/catch statement. Once
all referrals are processed, the groups array is finally returned.
Lastly, this patch changes how referred group hits are handled. This should
be open for discussion and testing. As it is, groups that are found at the
top level of the ecoinformatics.org LDAP tree will be returned as a relative
group name, such as cn=marine. However, any referral group hits get returned
as absolute URLs such as
ldap://directory.piscoweb.org:389/cn=data-managers,ou=groups,dc=piscoweb,dc=org??sub.
The above URL needs to be translated into an ecoinformatics.org-relative group.
Therefore, this patch does a second query to the ecoinformatics LDAP and finds
the point of the referral, in this case o=PISCOGROUPS,dc=ecoinformatics,dc=org.
The group is then rebuilt as cn=data-managers,o=PISCOGROUPS,dc=ecoinformatics,dc=org.
The question arises: Is this a good convention to stick to? It assumes (as
other parts of the Metacat code does) that groups are defined by commonName (cn)
attributes, and are located just below the top level of the referral point.
Perhaps there is a more flexible way to implement groups, but this way follows
the conventions thus far in the NCEAS, PISCO, LTER, and UCNRS LDAP servers.