Closed adeutscher closed 10 years ago
Starting on this ticket. Confirming the methods that I'm looking at.
Main methods:
getMultiAttributes
getObjectAttribute
Indirect methods (may update later):
getSingleAttribute
isObjectOfClass
getGroupMembers
Argh. Shelving for the moment.
My main reason for filing this was be able to filter out group members in group searches. However, I had forgotten that I don't actually touch the user object in the group search (memberOf
can't be relied on to be there, so as awesome as it can be I don't make use of it).
Perhaps a filterObjects
method that will take a list of UIDs and double-check them for attributes? Seems very messy, probably best to just stick with individual calls to get further attributes after getting a member list. It would go like this:
I pondered that some methods could use the option for additional filters.
For example,
isObjectOfClass
(which is used byisObjectUser
and in turngetGroupMembers
) could also filter by another criteria provided by the user (for example, account creation date or Active Directory'spasswdLastSet
property). Since these core methods supplement other classes, this would benefit a large number of methods.To avoid monstrous complexity and allow maximum customization, this argument would be provided by the user as an LDAP query string (e.g.
(passwdLastSet < 130459741190000000)
). The extra filter would be added onto the existing query as either an AND or an OR statement.This has implications for caching:
isObjectOfClass
call would invalidate either a cached positive or negative result unless you also cached the entire query.isObjectOfClass
call would not invalidate a successful result. A false result would be just as invalid as an OR statement - we wouldn't be able tell if the query failed because of the main check or the extra query.