On Tue, Dec 27, 2016 at 9:49 PM, Ben Caradoc-Davies <[email protected]>
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> - 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.
-------------------------------------------------------
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Geoserver-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
