Grouper Users - Open Discussion List

[Dominique Petitpierre <>]

Hello,
in the process of upgrading Grouper to version 2.4.0 I encounter some 
problems. Here are two:

1)
When doing an incremental search for a member in the "Add or remove members" 
interface, the following warning message occurs:

2019-09-12 21:25:59,562: [ajp-nio-127.0.0.1-8009-exec-2] WARN  
SubjectSourceCache.updateSubjectInCache(1112) -  - In subject source: 
peopletst the identifier: 'smith*' can find subject: '', but 
the attribute for that identifier is not configured in the subject source.  
In order for caching to be effective, please list all identifier attributes 
in the subject source.  You can configure to suppress this log message in 
subject config.
2019-09-12 21:25:59,562: [ajp-nio-127.0.0.1-8009-exec-2] DEBUG 
SubjectSourceCache.updateSubjectInCache(1169) -  - method: 
updateSubjectInCache, retrieved: true, accessed: true, 
subjectSourceCacheItemNull: true, subjectSourceCacheItemLookedUp: false, 
createdNewCacheItem: true, numberOfTimesRetrieved: 1, numberOfTimesAccessed: 
1, sourceId: peopletst, identifier: , createSubjectKeyCache: 
true, existingSubjectCacheKeySize: 0, identifier_unigechemployeeuid: smithd, 
identifier_unigechstudentuid: null, identifierNotConfigured: smith*, 
: true, addOrReplace_smithd: true, took: 
8248micros

The relevant configuration in subject.properties are done according to 
https://spaces.at.internet2.edu/display/Grouper/Grouper+Subject+API+caching+improvements+in+2.4
 :

# subject identifier to store in grouper's member table.  this is used to 
increase speed of loader and perhaps for provisioning
# you can have up to max 1 subject identifier
subjectApi.source.peopletst.param.subjectIdentifierAttribute0.value = 
unigeChEmployeeUid

# subject identifier to store in grouper's member table.  this is used to 
increase speed of loader and perhaps for provisioning
# you can have up to max 1 subject identifier
subjectApi.source.peopletst.param.subjectIdentifierAttribute1.value = 
unigeChStudentUid

Which is correctly read by Grouper:
gsh 1% 
SourceManager.getInstance().getSource("peopletst").getSubjectIdentifierAttributesAll();
java.util.LinkedHashMap: {0=unigechemployeeuid, 1=unigechstudentuid}

And the LDAP directory log shows the following corresponding searches:

Sep 12 21:25:59 peopletst1 slapd[76546]: conn=1018 op=8 SRCH 
base="ou=people,dc=unige,dc=ch" scope=1 deref=0 
filter="(&(?swissEduPersonUniqueID=smith*)(objectClass=unigeChPerson))"
Sep 12 21:25:59 peopletst1 slapd[76546]: conn=1018 op=10 SRCH 
base="ou=people,dc=unige,dc=ch" scope=1 deref=0 
filter="(&(uid=smith*)(objectClass=unigeChPerson))"
Sep 12 21:25:59 peopletst1 slapd[76546]: conn=1018 op=12 SRCH 
base="ou=people,dc=unige,dc=ch" scope=1 deref=0 
filter="(&(|(uid=smith)(cn=*smith*))(objectClass=unigeChPerson))"

corresponding to the following configured filters:

subjectApi.source.peopletst.search.searchSubject.param.filter.value = 
(&(swissEduPersonUniqueID=%TERM%)(objectclass=unigeChPerson))
subjectApi.source.peopletst.search.searchSubjectByIdentifier.param.filter.value
 = (&(uid=%TERM%)(objectclass=unigeChPerson))
subjectApi.source.peopletst.search.search.param.filter.value = (& 
(|(uid=%TERM%)(cn=*%TERM%*))(objectclass=unigeChPerson))


The debug log entry shows that the subjectIdentifierAttribute0 and 
subjectIdentifierAttribute1 are correctly assigned,
but somehow Grouper wants to find the value "smith*", which of course does 
not exist.

Presumably the incremental search /completion code uses the 
searchSubjectByIdentifier filter and adds a "*" to the %TERM% (smith*),
and that does not play well with the cache code which expects the %TERM% to 
be an exact match (smithd) for one of the subjectIdentifierAttributeN values.

Is there a way to fix that problem or is this a bug?


2)
The second issue is that a question mark is inserted in the searchSubject 
filter (cf. LDAP log above).
The search will never return any result. Strange!
I double checked: there is no invisible character in the subject.properties 
file for the searchSubject filter property.
In other context than incremental search that filter works properly with the 
correct value.

Again: Is there a way to fix that problem or is this a bug?


Note:
I actually was surprised by the way the incremental search works:
- it adds a "*" to query filters that were not supposed to have one (i.e. 
were meant for exact match),
  and in my case it caused problems because neither the 
swissEduPersonUniqueID (opaque identifier)
  nor the uid (very short) attribute were indexed for wildcard searches.
  (the Lite UI incremental search does not do that and uses only the 
search.search filter without adding wildcards)
- it does three different searches when one should be enough, especially that 
it is quite expensive anyway.
Suggestion:
May be a search.incrementalSearch.param.filter.value could be defined to 
allow for fine tuning incremental searches?

Thanks in advance for your help!

Regards,
-- 
Mr Dominique Petitpierre, user=Dominique.Petitpierre domain=unige.ch
IT Division, University of Geneva, Switzerland