Re: [uportal-dev] Issue searching on the 'username' attribute

[Eric Dalquist]

I'll see if I can get a chance to review this in the next few days. We're on day 4 of just cleaning up the basement so it might not be until Monday.

-Eric

On 10/4/12 4:33 PM, Drew Wills wrote:

Hey folks,

I developed a patch for the JIRA:

  - https://github.com/Jasig/person-directory/pull/2





drew

On 10/3/2012 5:53 PM, Drew Wills wrote:

I didn't commit it immediately because persondir code can be hard to follow, and it's not always clear what all the outcomes of a change will be. I can tell you this change eliminates the issue I was seeing. I'll give it some space for public comment, then pull it later if nothing unexpected surfaces.

I dug a bit deeper and created a JIRA:

   - https://issues.jasig.org/browse/PERSONDIR-66

drew

On 10/3/2012 4:10 PM, Drew Wills wrote:

Here's another piece of config that contributes to this puzzle...

     <util:list id="directoryQueryAttributes">
         <value>username</value>
         <value>givenName</value>
         <value>sn</value>
     </util:list>

That's what I had at first.  The behavior with that config was to set



the usernames of the 2 objects, and therefore the Set that was returned
from AbstractQueryPersonAttributeDao.getPeopleWithMultivaluedAttributes
contained only 1 entry.  (Every result was technically equal to every
other result.)

Although I *do* want to search on username, I temporarily changed it
to...

     <util:list id="directoryQueryAttributes">
         <value>givenName</value>
         <value>sn</value>
     </util:list>

This config had the effect of making every result's username attribute
null.

I was still getting a Set with 1 element returned, but this time ZERO
matches were displayed in the portlet screen.  (I guess the portlet
somewhere discards results without usernames.)

To me, the crux of the issue seems to lie in this...

I'm doing a search for all objects (in LDAP) matching...

   username='william' || givenName='william' || sn='william'

In my case, _none_ of the 93 results out of LDAP is owing to a match on
the first condition (username='william').  The
AbstractQueryPersonAttributeDao, however, seems to conclude that, since
I was searching for username='william' it must be the case that
username='william' for any results returned from LDAP.

I suppose that would be a safe assumption for a single-condition query,
but in this case it's not working out.

It seems like it would be better/safer to read the username from the
collection off attributes LDAP sends back.

But there are 2 challenges:
   - How do we know which attribute is the username?  (e.g. uid,
sAMAccountName, etc.)
   - What if that attribute is somehow not among those fetched?

Thoughts anyone?

drew


On 10/3/2012 3:22 PM, Drew Wills wrote:

each matches's 'username' attribute equal to the query string I entered. Instances if IPersonAttributes appear to implement equals() by comparing

I'm seeing something weird with PersonDirectory.

I have this in the config for an LdapPersonAttributeDao...

<property name="queryAttributeMapping">
   <map>
     <entry key="username" value="uid"/>
     <entry key="givenName" value="givenName"/>
     <entry key="sn" value="sn"/>
   </map>
</property>


LDAP.  But on the screen it only shows 1 result.

All but one match seem to be getting lost in the
AbstractQueryPersonAttributeDao.getPeopleWithMultivaluedAttributes
method.  It takes the raw results (93) from LDAP and converts them to
another format and places them in a Set of mappedPeople. For each item
it creates (and places in the Set) it seems to use the same value for

passed in, instead of from the results out of LDAP.



drew

Using a step-through debugger, I can see that 93 results come back from the 'username' attribute, which it's getting from the query parameters I I'm not positive what path is best for getting the desired behavior. I'm not sure I understand what all the parts of this setup are trying to do.

smime.p7s
Description: S/MIME Cryptographic Signature