Andrea,

- No objection, that sounds like a great idea to me.

- Yes to a new GSIP; the old one is already accepted. The new GSIP could 
include some descriptive text from the old one as GSIPs make great 
interim documentation (GSIP-152 being particularly good in my opinion). 
If all 5 types were summarised together that would be great.

Kind regards,
Ben.

On 16/12/16 00:17, Andrea Aime wrote:
> Hi,
> it turns out the layer group security proposal at
> https://github.com/geoserver/geoserver/wiki/GSIP-152
> improves the situation vs layer group security, it still fails to address
> some use cases.
>
> The use case in particular would be to have certain layers that are only
> accessible via an
> opaque layer group, but not by themselves, for certain users (fixed basemap
> approach)
> while for other users they are actually available via other other layer
> groups exposing them.
>
> I've been thinking about it and the simplest approach I can think to also
> match this requirement
> is to introduce a new type of layer group that would be an opaque
> container... it would be useful
> both in non secured environments, and paired with security:
>
>    - When used without security, it would implicitly make the layers
>    contained in it non advertised, as they would not appear anymore in the
>    capabilities document (unlike the existing SINGLE mode, which acts as an
>    alias but still leaves layers visible top level in the caps document). This
>    is a common situation that we missed a handy setup for (right now one has
>    to go and make each and every layer non advertised by hand). Mind, this
>    does not replace "non advertised", there are other legit uses of it, like a
>    top level layer that is the result of a computation and might be available
>    only temporarily.
>    - When used with security, it would allow expansion of the layer from
>    the group in GetMap, but not allow access to the layer directly
>
> In order to implement the latter the ResourceAccessManager interface would
> be extended with a method
> that takes a layer group and returns the layers the RAM wants to allow
> access to, instead of having
> SecureCatalogImpl just loop the contained layers one by one in isolation
> and authorize them directly.
> The new method would of course have a default implementation to make sure
> the interface is not broken.
>
> Two questions:
>
>    - Is there any objection?
>    - Should I make a separate GSIP for this?
>
> Cheers
> Andrea
>
>
>
> ------------------------------------------------------------------------------
> 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
>

-- 
Ben Caradoc-Davies <[email protected]>
Director
Transient Software Limited <http://transient.nz/>
New Zealand

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

Reply via email to