Ben Alex (Migrated from SEC-16) said:
If a Collection/array of domain objects are presented to BasicAclEntryAfterInvocationCollectionFilteringProvider, the filtering will occur at the level of the presented Collection/array only.
We should consider adding a feature to BasicAclEntryAfterInvocationCollectionFilteringProvider that allows it to reflectively evaluate each property to locate internal Collections/arrays. These would then be processed at an ACL level. This would continue so any level of object nesting is processed. It would be necessary to avoid infinite loops, as one object may refer (by reference) to a parent object. The Acegi Security domain subproject contains some examples of this sort of detection behaviour in its validation package.
Such a new feature must be switchable, as the expense of reflectively evaluating every domain object in a Collection/array may be high.
Ben Alex said:
Should be against component SecurityACL.
Luke Taylor said:
I think this requirement should (at least partially) be possible using the new expression syntax. For example, if filtering a Person domain object, the expression
hasPermission(filterObject, ‘read’) and hasPermission(filterObject.address, ‘read’)
should evaluate the read permission on both the object itself and a contained “address”. It should also be possible to extend the logic to handle checking permissions on each member of a collection directly e.g.
hasPermission(filterObject, ‘read’) and hasPermission(filterObject.addresses, ‘read’)
Closing. As indicated, the expression support allows for more sophisticated ACL controls than just at the level of a collection argument.