[Geoserver-devel] changing/fixing behaviour of local styles and layer groups

Justin_Deoliveira · February 5, 2014, 2:40am

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

Andrea_Aime4 · February 5, 2014, 12:10pm

On Wed, Feb 5, 2014 at 3:40 AM, Justin Deoliveira <jdeolive@anonymised.com

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?

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.

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...

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 · February 5, 2014, 4:05pm

On Wed, Feb 5, 2014 at 5:10 AM, Andrea Aime <andrea.aime@anonymised.com>wrote:

On Wed, Feb 5, 2014 at 3:40 AM, Justin Deoliveira <
jdeolive@anonymised.com> 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
jdeolive@anonymised.com
@j_deolive <https://twitter.com/j_deolive>

Andrea_Aime4 · February 5, 2014, 4:12pm

On Wed, Feb 5, 2014 at 5:05 PM, Justin Deoliveira <jdeolive@anonymised.com