On Fri, Mar 14, 2014 at 6:59 PM, Kevin Smith <ksm...@boundlessgeo.com>wrote:
> Yes, although the presence of post-filters at all is the big problem.
> Moving some of the logic to pre will help a little, but to get the big
> performance payoff, at least for cases like the Layer Preview page, it has
> to all be pre.
>
> It appeared that AdvertisedCatalog assumes layer groups could have
> sub-layergroups while LayerPreviewProvider assumes they only contain
> layers.
>
Ah, the latter seems an oversight of when nested layer groups where
implemented, it should work like AdvertisedCatalog instead.
> If it does need to recurse through nested groups, a CTE query should be
> able to handle it, although not all DBs support that so there would have to
> be a check for SQL dialect and a fall back to a post filter if CTE is not
> supported.
>
Right. Alternatively, implement some sort of derived property that you have
in the DB, and that is getting updated recursively when a nested attribute
changes
>
>>
>>>
>>> The Security filter is far more complicated though. However all it's
>>> needed for is to hide inaccessible layers. Making layers that the user
>>> can't read visible in those lists (the security wrapper would still prevent
>>> reading of the layers). Either an option to disable hiding these layers, or
>>> having JDBCConfig do it automatically would resolve this part of the
>>> problem.
>>>
>>
>> Hmm... the current ResourceAccessManager is designed to work against an
>> in memory catalog, it gives you access resource
>> by resource, in order to deal with a large amount of layer with security
>> it needs to be modified to return a Filter that will
>> locate, or at least pre-filter, all accessible objects of a given kind,
>> something like:
>>
>> Filter getAccessibleCatalgoInfos(Class catalogInfoType);
>>
>> which would for example be called like:
>> ram.getAccessibleCatalgoInfos(DataStoreInfo.class); --> filter that
>> restricts the stores we can see
>> ram.getAccessibleCatalgoInfos(LayerInfo.class); --> filter that restricts
>> the layers we can see
>>
>> and then the existing methods would be used either as a secondary filter
>> (maybe some parts of the access control
>> cannot be turned into a filter) and/or to apply access lmitations (e.g.
>> yes, you can see layer x, but only a subset of its attributes).
>> This will break existing implementations of ResourceAccessManager, so it
>> requires a GSIP.
>>
>
> If we leave anything as a post-filter it will disable database side paging
> and counting which are what I'm trying to get working. Wrappers are fine
> though. I tried to follow the logic of how the current filter is built,
> but there seem to be too many places where new behaviour can be plugged in
> with extension points and wrappers for it to be practical to re-implement
> in SQL. I'm not too familiar with the security system though. I didn't go
> much beyond the buildWrapperPolicy methods on SecureCatalogImpl while
> looking into this.
>
I cannot guarantee a security implementation can do all its work without
doing post filtering (as noted above, it might have to drill down in the
object structure to check some attribute in referenced entities). But we
could have an interface that tells if you if post filtering is going to be
needed, or not, and lets you optimize the first case.
Cheers
Andrea
--
==
Meet us at GEO Business 2014! in London! Visit http://goo.gl/fES3aK
for more information.
==
Ing. Andrea Aime
@geowolf
Technical Lead
GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549
http://www.geo-solutions.it
http://twitter.com/geosolutions_it
-------------------------------------------------------
------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/13534_NeoTech
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
