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