[Geoserver-devel] GeoTools / GeoServer Meeting 2016-12-27

GeoServer GeoServer Developer
1

GeoTools / GeoServer Meeting 2016-12-27

# Attending

Ben Caradoc-Davies, Jody Garnett

Agenda- OSGeo Budget

  • Sprint Planning

  • OSGeo Live

OSGeo Budget

 - Sent in a draft budget similar to last year; helps with board planning
  • Draft based on having a geoserver sprint

Sprint Planning

 - See email list discussion - GeoSolutions offering to host this year!

  • Dates TBD (the original suggestion was for Feb 13 to end of March)

  • Interested visitors: Ian, Mike, Jody, Torben, Devon

  • Action: Request that Andrea make a blog post

  • Action: Run up a draft budget with travel / accommodation / etc…

  • Details

  • CITE Test Sprint

  • SPI replacement for Java 9?

OSGeo Live

 - Latest alpha upgraded to GeoServer 2.10.1 - woo hoo!

  • Upgrade to Jetty 9 caused some work

  • NetCDF quickstart pending

Discussion

 - NetCDF variable discussion on mailing list; awaiting clarification …

Okay making a table to sort out what is what …



Layer group

|

Named

|

Children

|

Advertised Children

|

Access Restrictions

|

  • | - | - | - | - |


    Single

    |

    named

    |
    |

    layer default

    |

    layer default

    |


    Named tree

    |

    named

    |

    Lists children

    |

    layer default

    |

    Layer default

    |


    Container Tree

    |
    |

    Lists children

    |

    layer default

    |

    Layer default

    |


    EO Tree

    |

    Named delegate

    |

    Lists children

    |

    layer default

    |

    Layer default

    |


    Opaque Container

    |

    named

    |
    |

    Not advertised

    |
    |

Q: Because the children are not advertised by “opaque container” why does the access restrictions even matter?

Q: Are the access restrictions any different between “Named tree” and ‘Opaque container”?

  • Ben cannot see a difference

  • Jody cannot see why it matters (since the layers are not published here)

Q: Can we break out these qualities as checkboxes rather than as a “mode” setting?

  • Tree

  • (true) controls if children are listed in the capabilities document; or

  • (false) layer group is is presented as a single layer in the capabilities document

  • Advertise Layer Group

  • (true) layer group is listed in the capabilities document

  • (false) layer group is not listed in the capabilities document

  • Advertise Children

  • (true) layers use their default “advertised” setting

  • (false) layers are not advertised in the capabilities document here (yes another layer group may wish to advertise them)

  • Named

  • (true) layer group name can be used to request the layer group be drawn (treats the layer group as a single layer that can be drawn using GetMap)

  • (false) layer group name is for internal use only, and cannot be used in a GetMap Request (treats the layergroup as a folder that cannot be requested using GetMap)

  • Delegate Layer

  • If a delegate is provided this layer will be drawn instead when the layer group is requested

  • Restricted

  • Layer group is available as target for access control restrictions

··· 
-- 
Ben Caradoc-Davies [<ben@anonymised.com>](mailto:ben@anonymised.com)
Director
Transient Software Limited [<http://transient.nz/>](http://transient.nz/)
New Zealand
2

On Tue, Dec 27, 2016 at 9:49 PM, Ben Caradoc-Davies <ben@anonymised.com>
wrote:

*GeoTools / GeoServer Meeting 2016-12-27*

* Attending Ben Caradoc-Davies, Jody Garnett*

Forgot to send my apologies, my kids are home for vacations and I'm on baby
sitting duty
full time (I have vacations, my wife does not).

* - - GSIP 153 Opaque container layer group
<https://github.com/geoserver/geoserver/wiki/GSIP-153&gt; - Ben did not like
any of Jody’s suggestions better than “opaque container” layergroup -
Should a layer contained in an “opaque container” have the advertised
checkbox grayed out?*

Nope, a layer can appear in multiple groups.

* - - Ben: “Withheld”? “Unadvertised”? - Properties of a single class?
Okay making a table to sort out what is what ... Layer group Named Children
Advertised Children Access Restrictions Single named layer default layer
default Named tree named Lists children layer default Layer default
Container Tree Lists children layer default Layer default EO Tree Named
delegate Lists children layer default Layer default Opaque Container named
Not advertised *

The above table seems to be wrong in regards to access restrictions due to
GSIP 152, if a layer
shows up in a tree group that has been denied, then it won't be accessible
at all (nor by the group, nor by itself),
unless it's also available by another group (a layer can be part of
multiple groups).

* Q: Because the children are not advertised by “opaque container” why
does the access restrictions even matter?*

Because one can access unadvertised layers directly, and the layer name can
be inferred by other means, e.g., by performing
a GetFeaturInfo on the group.
During the implementation I actually figured out that part of what I was
proposing did not make sense, if a layer
is only in a opaque container it's not available at all by itself, putting
it there is the security itself, there is nothing
more to do in terms of data security rules. I wanted to discuss this once I
came back from vacations, but here we go...

* Q: Are the access restrictions any different between “Named tree” and
‘Opaque container”? - Ben cannot see a difference - Jody cannot see why it
matters (since the layers are not published here)*

A named tree that allows access show the layers and allows direct access to
them. If it's denied by security, the
layers have the same destiny, unless contained in other visible groups.

A opaque container is the "only" conduit to access the layers it contains,
layer cannot be accessed directly by name in GetMap
unless they are also contained in other visible groups.

* - Q: Can we break out these qualities as checkboxes rather than as a
“mode” setting?*

This would imply a redesign of the entire system. Feel free to make it into
a proposal and implement it, taking care of backwards compatibility.
GSIP-153 has been positively voted by the both of you (to be fair, I would
not have had the developer resources to implement what you propose
here anyways, GSIP-153 would have died there if you went forward with this
before voting).

* - Tree - (true) controls if children are listed in the capabilities
document; or - (false) layer group is is presented as a single layer in the
capabilities document - Advertise Layer Group - (true) layer group is
listed in the capabilities document - (false) layer group is not listed in
the capabilities document*

* - Advertise Children - (true) layers use their default “advertised”
setting - (false) layers are not advertised in the capabilities document
here (yes another layer group may wish to advertise them) *

* - Named - (true) layer group name can be used to request the layer group
be drawn (treats the layer group as a single layer that can be drawn using
GetMap) - (false) layer group name is for internal use only, and cannot be
used in a GetMap Request (treats the layergroup as a folder that cannot be
requested using GetMap)*

A non named group is not "internal use only", it's a legit part of the
capabilites document tree, it just cannot be requested in GetMap (maybe we
are saying the same thing with different words).

* - Delegate Layer - If a delegate is provided this layer will be drawn
instead when the layer group is requested*

This weirdness is EO specific, I giving it a different name would only
cause confusion imho.

* - - Restricted - Layer group is available as target for access control
restrictions*

I don't get this one, all groups are targets for access control
restrictions as per GSIP-152 already. I however do not see a combination
that would allow a layer group to make layers truly unavailable in a
basemap fashion (that is, either access them thought the group, or they
are locked up for good).

Giving uses 6 separate flags would mean allowing for 64 different potential
configurations instead of the 5 proposed. Seems like a nightmare to
understand and test, and some combinations would seem to be illegal to
start with, for example, a tree group that does not advertise children...
then it's not a tree? One would have to enumerate all possible cases and
see if they make sense, and then develop a set of tests at the catalog,
security and WMS caps level for each combination (see the tests I've
created for the work in progress for GSIP 153)... it would seem one would
have to develop something like 200 new tests.

Regards
Andrea

--

GeoServer Professional Services from the experts! Visit
http://goo.gl/it488V for more information.

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via di Montramito 3/A
55054 Massarosa (LU)
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

*AVVERTENZE AI SENSI DEL D.Lgs. 196/2003*

Le informazioni contenute in questo messaggio di posta elettronica e/o
nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il
loro utilizzo è consentito esclusivamente al destinatario del messaggio,
per le finalità indicate nel messaggio stesso. Qualora riceviate questo
messaggio senza esserne il destinatario, Vi preghiamo cortesemente di
darcene notizia via e-mail e di procedere alla distruzione del messaggio
stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso,
divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od
utilizzarlo per finalità diverse, costituisce comportamento contrario ai
principi dettati dal D.Lgs. 196/2003.

The information in this message and/or attachments, is intended solely for
the attention and use of the named addressee(s) and may be confidential or
proprietary in nature or covered by the provisions of privacy act
(Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection
Code).Any use not in accord with its purpose, any disclosure, reproduction,
copying, distribution, or either dissemination, either whole or partial, is
strictly forbidden except previous formal approval of the named
addressee(s). If you are not the intended recipient, please contact
immediately the sender by telephone, fax or e-mail and delete the
information in this message that has been received in error. The sender
does not give any warranty or accept liability as the content, accuracy or
completeness of sent messages and accepts no responsibility for changes
made after they were sent or for other risks which arise as a result of
e-mail transmission, viruses, etc.

-------------------------------------------------------

3

Thanks for the discussion Andrea / Ben:

Focusing on understanding GSIP-153 (rather than alternatives):

* Layer group Named Children Advertised Children Access

Restrictions Single named layer default layer default Named tree named
Lists children layer default Layer default Container Tree Lists children
layer default Layer default EO Tree Named delegate Lists children layer
default Layer default Opaque Container named Not advertised *

The above table seems to be wrong in regards to access restrictions due to
GSIP 152, if a layer
shows up in a tree group that has been denied, then it won't be accessible
at all (nor by the group, nor by itself),
unless it's also available by another group (a layer can be part of
multiple groups).

Yeah I think I got the wrong flavour here for "advertised children". For a
"basemap" / "opaque container" layer group the children are more than "not
advertised' they are "unnamed / not requestable" (unless published
elsewhere by another layer group).

I would like to include the above table in your proposal page as it helps
me understand what the different layer groups types mean.

* Q: Because the children are not advertised by “opaque container” why
does the access restrictions even matter?*

Because one can access unadvertised layers directly, and the layer name
can be inferred by other means, e.g., by performing
a GetFeaturInfo on the group.

Oh, so they are still accessable individual using GetMap?

During the implementation I actually figured out that part of what I was
proposing did not make sense, if a layer
is only in a opaque container it's not available at all by itself, putting
it there is the security itself, there is nothing
more to do in terms of data security rules. I wanted to discuss this once
I came back from vacations, but here we go...

This is what I was thinking ... you have a belt and suspenders to keep your
pants on.

* Q: Are the access restrictions any different between “Named tree”

and ‘Opaque container”? - Ben cannot see a difference - Jody cannot see why
it matters (since the layers are not published here)*

A named tree that allows access show the layers and allows direct access
to them. If it's denied by security, the
layers have the same destiny, unless contained in other visible groups.

A opaque container is the "only" conduit to access the layers it contains,
layer cannot be accessed directly by name in GetMap
unless they are also contained in other visible groups.

So this question is mostly a variation on the above; if they are not
accessible at all then security settings do not matter.

So here is the clarification/confirmation: When accessed by "other visible
group" they are under the security restrictions of that other group; the
security restrictions from the "opaque container" do not have any affect.

basemap (opaque container) with restriction "basemap/*' for "operations"
- roads
- orthophoto
infrastructure (named tree) with restrictions to "maintenance"
- roads

Someone from the public:
- can see a capabilities document with "basemap" listed
- they can draw basemap, but operations like GetFeatureInfo fail to return
anything useful (since they have security restrictions preventing access to
roads and orthophotos)

Someone from operations:
- can see a capabilities document with "basemap listed" (but no further
detail)
- can use GetFeatureInfo to see some details about roads and orthophoto
since they have security access to roads and orthophotos

Someone from infrastructure:
- can see basemap (just like a member of public) and can see infrastructure
and its contents
- they can draw basemap, but operations like GetFeatureInfo will only
respond to roads (not orthophoto) since that is the only layer they have
security permission to see
- they can draw infrastructure since it is a named tree
- they can draw and interact with roads (since they can access it via
infrastructure)

4

On Wed, Dec 28, 2016 at 7:50 PM, Jody Garnett <jody.garnett@anonymised.com>
wrote:
| I would like to include the above table in your proposal page as it helps
me understand what the different layer groups types mean.

Err... ok, it needs fixing but I can amend the proposal to include a
corrected version of it. I'm surprised in that the first four rows are
things everybody should have known
already.

Because one can access unadvertised layers directly, and the layer name
can be inferred by other means, e.g., by performing

a GetFeaturInfo on the group.

Oh, so they are still accessable individual using GetMap?

A non advertised layer is still requestable directly. That's the point of
novelty of the opaque container, you can ask for the group, but there
is no way to take it apart in its constituents, even if the client is
custom made and can in theory ask for the layers
directly.

* Q: Are the access restrictions any different between “Named tree”

and ‘Opaque container”? - Ben cannot see a difference - Jody cannot see why
it matters (since the layers are not published here)*

A named tree that allows access show the layers and allows direct access
to them. If it's denied by security, the
layers have the same destiny, unless contained in other visible groups.

A opaque container is the "only" conduit to access the layers it
contains, layer cannot be accessed directly by name in GetMap
unless they are also contained in other visible groups.

So this question is mostly a variation on the above; if they are not
accessible at all then security settings do not matter.

So here is the clarification/confirmation: When accessed by "other
visible group" they are under the security restrictions of that other
group; the security restrictions from the "opaque container" do not have
any affect.

Correct.

basemap (opaque container) with restriction "basemap/*' for "operations"
- roads
- orthophoto
infrastructure (named tree) with restrictions to "maintenance"
- roads

Someone from the public:
- can see a capabilities document with "basemap" listed
- they can draw basemap, but operations like GetFeatureInfo fail to return
anything useful (since they have security restrictions preventing access to
roads and orthophotos)

Nope, if the basemap is restricted to operations the public will not see
it. From your layout above, the public won't see anything.

Someone from operations:
- can see a capabilities document with "basemap listed" (but no further
detail)
- can use GetFeatureInfo to see some details about roads and orthophoto
since they have security access to roads and orthophotos

Correct

Someone from infrastructure:
- can see basemap (just like a member of public) and can see
infrastructure and its contents

- they can draw basemap, but operations like GetFeatureInfo will only

respond to roads (not orthophoto) since that is the only layer they have
security permission to see

No and no, see above, only someone from operations can see basemap.

- they can draw infrastructure since it is a named tree

They can draw it since they have access to it _and_ it's a named tree.

- they can draw and interact with roads (since they can access it via
infrastructure)

Correct.

Let me make an example closer to the intended usage.

basemap (opaque container) with no restrictions
- roads
- orthophoto
referenceTree (named tree) restricted to "logged in user"
- roads
- orthophoto

Someone from the public can only see basemap, cannot many any request
directly asking roads and orthophoto, when a GetFeatureInfo is run against
basemap they will get information as usual since the access went through
the group.

Someone from the "logged in user" group can do anything on all layers,
since they are all visible to them.

Regards
Andrea

--

GeoServer Professional Services from the experts! Visit
http://goo.gl/it488V for more information.

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via di Montramito 3/A
55054 Massarosa (LU)
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

*AVVERTENZE AI SENSI DEL D.Lgs. 196/2003*

Le informazioni contenute in questo messaggio di posta elettronica e/o
nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il
loro utilizzo è consentito esclusivamente al destinatario del messaggio,
per le finalità indicate nel messaggio stesso. Qualora riceviate questo
messaggio senza esserne il destinatario, Vi preghiamo cortesemente di
darcene notizia via e-mail e di procedere alla distruzione del messaggio
stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso,
divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od
utilizzarlo per finalità diverse, costituisce comportamento contrario ai
principi dettati dal D.Lgs. 196/2003.

The information in this message and/or attachments, is intended solely for
the attention and use of the named addressee(s) and may be confidential or
proprietary in nature or covered by the provisions of privacy act
(Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection
Code).Any use not in accord with its purpose, any disclosure, reproduction,
copying, distribution, or either dissemination, either whole or partial, is
strictly forbidden except previous formal approval of the named
addressee(s). If you are not the intended recipient, please contact
immediately the sender by telephone, fax or e-mail and delete the
information in this message that has been received in error. The sender
does not give any warranty or accept liability as the content, accuracy or
completeness of sent messages and accepts no responsibility for changes
made after they were sent or for other risks which arise as a result of
e-mail transmission, viruses, etc.

-------------------------------------------------------

5

On 29/12/16 06:44, Andrea Aime wrote:

Giving uses 6 separate flags would mean allowing for 64 different potential
configurations instead of the 5 proposed. Seems like a nightmare to
understand and test, and some combinations would seem to be illegal to
start with, for example, a tree group that does not advertise children...
then it's not a tree? One would have to enumerate all possible cases and
see if they make sense, and then develop a set of tests at the catalog,
security and WMS caps level for each combination (see the tests I've
created for the work in progress for GSIP 153)... it would seem one would
have to develop something like 200 new tests.

I recognise that the use of properties rather than a small number of classes makes testing harder. This approach may be too general, for the reasons you detail above. Restriction through subclassing can be a good thing, and I am comfortable with it; I was just trying to identify the orthogonal characteristics of the problem, not saying that all combinations are valid or that exposing them is desirable.

Kind regards,

--
Ben Caradoc-Davies <ben@anonymised.com>
Director
Transient Software Limited <http://transient.nz/&gt;
New Zealand