Metacat

What was the EML document?
Are there any records in the xml_access table for this document?

In dev metacat, the eml document is is doc.1292979786139.1. And owner is uid=maanand,o=unaffiliated,dc=ecoinformatics,dc=org.

This document was generated by a workflow which was created by manish from SDSC. The worklfow will upload metadata (eml format) and data from dataturbine to a metacat.

There is no any record in xml_access table for the eml.

I tried this on two local machines (running from svn trunk) and then on dev.nceas.ucsb.edu. In al cases, the owner was able to view the document.
For dev I had to edit the online distribution URL so that I didn't appear to be messing with an existing data table.
Here's the example on dev (login as kepler user first):
http://dev.nceas.ucsb.edu/knb/metacat?action=read&docid=brl.1.1&qformat=default

Somehow, in EcogridWriter actor, author put an extra space after uid=kepler,o=unaffiliated,dc=ecoinformatics,dc=org.

So the "uid=kepler,o=unaffiliated,dc=ecoinformatics,dc=org " was recorded as the owner. "uid=kepler,o=unaffiliated,dc=ecoinformatics,dc=org" is not recognized as the owner.

We need to trim the string before we record it to the xml_documents table

Trimming strings on input like this is always dangerous. My guess is that the bug arises because someone through a 'trim' in on the original login field, which allowed someone to authenticate incorrectly in the first place. a user DN should be an exact match to what is in LDAP (without any trimming), and if it is not it should be rejected both for login and for any access control checks.

Jing -- can you check and see if someone can log in successfully if they have a space following their DN, and if so stop that from happening?

Throwing in a trim() call here or there just eliminates any precision we had and creates a bunch of corner cases that we have to deal with in the code wherever that field is referenced.

Hi, Matt:

Yes, the user name with extra space can login. The username field in EcogridWriter is used for login. The workflow working means the the username (with extra space) and password can login successfully.

I just browsed the code and didn't find any trimming in username. But I will take a close look.

Hrrm, it seems our code doesn't trim the username.

In AuthLdap.authenticateTLS:

I added a information line to display the userName.

ctx.addToEnvironment(Context.SECURITY_AUTHENTICATION, "simple");
System.out.println("===============The userDN is "+userDN+".")
ctx.addToEnvironment(Context.SECURITY_PRINCIPAL, userDN);
ctx.addToEnvironment(Context.SECURITY_CREDENTIALS, password);
ctx.reconnect(null);

The output is:
===============The userDN is uid=tao,o=NCEAS,dc=ecoinformatics,dc=org .

So our metacat doesn't trim the username variable, the correct username was passed to the javax.naming.ldap.LdapContext object. But the login still succeed with the username having extra space.

This means we can't modify it since trimming doesn't happen in our source code space.

Did I miss anything?

Probably solution is to use Java's canonicalization routines to normalize the DN, as Ben has done on the DataONE DNs. For now it will rarely be encountered so delaying work on it.

Original Bugzilla ID was 5262