Skip to Content.
Sympa Menu

grouper-users - [grouper-users] subject cache warning: "the attribute for that identifier is not configured" + question mark added to LDAP search filter

Subject: Grouper Users - Open Discussion List

List archive

[grouper-users] subject cache warning: "the attribute for that identifier is not configured" + question mark added to LDAP search filter


Chronological Thread 
  • From: Dominique Petitpierre <>
  • To: "" <>
  • Subject: [grouper-users] subject cache warning: "the attribute for that identifier is not configured" + question mark added to LDAP search filter
  • Date: Thu, 12 Sep 2019 22:52:40 +0200
  • Organization: University of Geneva

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



Archive powered by MHonArc 2.6.19.

Top of Page