On Wed, Feb 5, 2014 at 5:10 AM, Andrea Aime <[email protected]>wrote:
> On Wed, Feb 5, 2014 at 3:40 AM, Justin Deoliveira <
> [email protected]> wrote:
>
>> Hi all,
>>
>> As people are aware there are a few issues outstanding with the way that
>> local styles and layer groups are implemented. I've been looking at what it
>> will take to fix and think I have a plan but want to get a sanity check
>> first.
>>
>> First, reviewing how things are implemented now. Basically any request
>> that isn't local to the workspace filters out all styles and layer groups
>> that are local to a workspace. This approach has a couple of issues.
>>
>> 1. It deviates from the way we handle layers, which are also contained
>> with a workspace.
>> 2. There are bugs like GEOS-6026 that produce invalid WMS urls resulting
>> from a global endpoint referencing a local style.
>>
>> So, how do we fix this? The idea is to have local styles and layer groups
>> behave sort of like un-advertised layer do. Basically for a GetCapabilities
>> request that is through a workspace endpoint we apply the filter. For the
>> global endpoint we don't do any filtering. For non capabilities requests we
>> also don't do any filtering either.
>>
>> With this approach we enable cross workspace, or global to local (and
>> vice versa) access of styles. To facilitate this we'll need to support
>> qualified style and layer group names. Which we actually already do.
>> However, there is a small wrinkle. Consider a global style named "foo", and
>> as well a style local to "topp" named "foo". What style does the following
>> request refer to?
>>
>> /geoserver/topp/wms?styles=foo
>>
>> The way things are implemented currently is that a local style takes
>> precedence over a global one with the same name. Which I think makes sense
>> and we'll want to continue to support. But what if I actually want to refer
>> to the global style? My thinking here is that we support the "empty" prefix
>> to mean global. So the following request would refer to the global style:
>>
>> /geoserver/topp/wms?styles=:foo
>>
>> Or we could simply not allow access to the global style... but I think
>> that would be somewhat inconsistent because with this new scheme we would
>> allow for accessing a style from a separate workspace:
>>
>> /geoserver/topp/wms?styles=tiger:foo
>>
>> So why not allow for access to global as well. In the case where there is
>> no local override an unqualified name would resolve to the global style
>> naturally.
>>
>
> So far it seemed all good, but here I lost you. Why we we want to allow
> access to a separate workspace styles, from within one workspace?
> Doesn't this break isolation when the workspaces are used to separate
> different "customers" in a multi-tenant installation?
>
> Right... this approach would change that with the idea being to allow
access to workspace local information from the global context. I guess I
figured if we were doing that why not allow access across workspaces. But
it sounds like we would rather have it work so that global can access
local, but local can't access another local. Which makes sense from a multi
tenancy standpoint.
> Also question, administration wise, is it possible today to refer from
> layer w1:layer to a style in another workspace, say w2?
> Or using REST, for what is worth.
>
It is if you have full admin, but if you only have admin to a single
workspace then you can't see the style in the w2. However if you do this
and go through the local workspace endpoint for a WMS request you will
receive an error, like the one Jukka reported.
>
>> And that is basically the idea. Codewise the changes should be relatively
>> constrained to the following areas off the top of my head:
>>
>> - The filtering logic in LocalWorkspaceCatalogFilter and
>> LocalWorkspaceCatalog will change
>> - StyleInfo and LayerGroupInfo will need a "prefixedName()" similar to
>> LayerInfo
>> - WMS capabilities endpoint will need to use prefixedName() when
>> referencing styles
>>
>
> Except that if the style is global, we simply use the name, and not
> ":name"?
> I mean, :name looks ugly, I see the benefit of using it to break an
> ambiguity, but having it show by default seems too much.
> There is a wrinkle here too though, we'll need to refer to :name if the
> layer is referring to a global style, and there is a local one with the
> same name...
>
Right, it's only needed in cases where there is a "local override". We
could do a check for this case and only use the qualified syntax in the
case where there is actually a local override. The alternative would be to
not allow access to the global style when going through the workspace
endpoint.
>
>
>> Finally, timing wise the plan if folks agree would be to implement on a
>> branch and merge in when master is ready for core/unstable changes. From my
>> side there is no client driving this so I don't have any need to backport
>> but if folks are happy with the change and think its stable enough we can
>> backport accordingly.
>>
>
> Agreed
>
> Cheers
> Andrea
>
>
> --
> == Our support, Your Success! Visit http://opensdi.geo-solutions.it 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
>
> -------------------------------------------------------
>
--
*Justin Deoliveira*
Vice President, Engineering | Boundless
[email protected]
@j_deolive <https://twitter.com/j_deolive>
------------------------------------------------------------------------------
Managing the Performance of Cloud-Based Applications
Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
Read the Whitepaper.
http://pubads.g.doubleclick.net/gampad/clk?id=121051231&iu=/4140/ostg.clktrk
_______________________________________________
Geoserver-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
