Hi,
The big picture is too complicated for me but I believe that I would be happy if all the styles which are advertised in GetCapabilities were also usable in &STYLES= so that the standard WMS clients could not pick a style that will lead to an error. It might still feel odd if the global service is advertising a style like “mil:troops” and it could be applied to a layer but probably it is not a big secret anyways that the service has a workspace “mil” and hopefully nobody makes layers into public service by filtering out the confidential data with SLD. These short questions came into my mind.
-
Does/could/should Geoverver security limit access to workspace specific styles?
-
Can advertising workspace specific styles in the global service leak info about how many and what sort of customers a service provider has?
-
Is it valid and wise to use a qualified name without prefix as in ”/geoserver/topp/wms?styles=:foo”?
-Jukka Rahkonen-
···
Justin Deoliveira 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.
-
It deviates from the way we handle layers, which are also contained with a workspace.
-
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.
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
-
CatalogImpl and LocalWorkspaceCatalog will need a few tweaks with regard to name looks ups to handle style and layer group qualified names
There are probably a few more in there as well.
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.
Thoughts?
–
Justin Deoliveira
Vice President, Engineering | Boundless
jdeolive@anonymised.com
@j_deolive