Hey folks,
I developed a patch for the JIRA:
- https://github.com/Jasig/person-directory/pull/2
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.
drew
On 10/3/2012 5:53 PM, Drew Wills wrote:
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
each matches's 'username' attribute equal to the query string I entered.
Instances if IPersonAttributes appear to implement equals() by comparing
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:
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>
Using a step-through debugger, I can see that 93 results come back from
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
the 'username' attribute, which it's getting from the query parameters I
passed in, instead of from the results out of LDAP.
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.
drew
--
You are currently subscribed to [email protected] as:
[email protected]
To unsubscribe, change settings or access archives, see
http://www.ja-sig.org/wiki/display/JSG/uportal-dev
