This page last changed on May 02, 2014 by groldan.


Add methods to ResourceAccessManager and CatalogFilter to allow them to build the filter currently built by SecureCatalogImpl.

Proposed By

Kevin Smith

Assigned to Release



Under Discussion


Catalog queries against large JDBCConfig backed catalogs can be severly impacted by the presence of filters that are not "well known". Moving responsibility for building the security filter to the ResourceAccessManager which determines which objects need to be filtered, allows for well known filters to be used when it is possible to do so.


The following method would be added to ResourceAccessManager

Filter ResourceAccessManager.getSecurityFilter(Authentication user, Class<? extends CatalogInfo> clazz)

This would return a Filter which when applied to a CatalogInfo would remove it if the getAccessLimits would have hidden it by returning an AccessLimits that specified that the user can't read it, and that non-readable should be hidden.

SecureCatalogImpl can then use that filter rather than building one which retreives the AccessLimits and checks whether it should hide the object based on that.

CatalogFilterAccessManager bases its filtering on CatalogFilter objects.  Extending that interface in the same way would allow CatalogFilterAccessManager to build well known filters if all of its CatalogFilters produce well known filters.

Filter CatalogFilter.getSecurityFilter(Class<? extends CatalogInfo> clazz)


This section should contain feedback provided by PSC members who may have a problem with the proposal.

Backwards Compatibility

This adds new methods to interfaces used as public extension points.   GeoFence and GeoShield use these extension points.


Alessio Fabiani: +1
Andrea Aime: +1
Ben Caradoc-Davies:
Christian Mueller:
Gabriel Roldán: +1
Jody Garnett: +1
Jukka Rahkonen:
Justin Deoliveira:
Phil Scadden:
Simone Giannecchini:


Email Discussion

Document generated by Confluence on May 14, 2014 23:00