[Geoserver-devel] working through GSIP 73 feedback

GeoServer GeoServer Developer
1

Hi all,

I have been working through the feedback gathered for GSIP 73.

http://geoserver.org/display/GEOS/GSIP+73±+Workspace+Local+Styles+and+Layer+Groups

From the email exchange earlier this week this the major feedback I mined out of it:

  1. rest api needs to be updated
  2. better ui for local workspace stuff, ideally a single global workspace drop down
  3. more care taken when updating the ResourceAccessManager interface
  4. ResourceAccessManager might not be the best place for simply filtering styles and layer groups

(1) has been completed. Will update patch shortly.

(2) I would like to push off as a future improvement. I thought about it and I think it represents quite a bit of work, but i do agree it would be a much better workflow.

(3) Added an abstract base class for the ResourceAccessManager that extensions can extend from, protecting them from future api changes

(4) This one i am torn on and allow me to explain. I agree that the ResourceAccessManager should really be used strictly for security, but on the other hand we currently do use it for filtering components of the catalog. And the CatalogFilter interface already supports some catalog components so why not others.

As previously mentioned for this proposal I had to add a second catalog wrapper called LocalWorkspaceCatalog, to do some special handling around local workspace stuff. I could move all the local workspace filtering stuff there and away from the CatalogFilter interface. But then we would be duplicating a lot of the stuff done in SecureCatalog to do filtering of the various catalog contents. This is actually more inline with how the local workspace stuff was originally implemented but then it was decided that using the CatalogFilter interface would be a good idea for that.

To decide which way to go I would like to ask a secondary question. Does having access limits for styles and layer groups make sense, in any context, not just a workspace local context? If it doesn’t then i can remove those interface and move everything over to the LocalWorkspaceCatalog wrapper.

However if those interfaces do make sense then the fact that we use them for this filtering is really just an implementation detail, and we could potentally leave things as is now and move them over at a later time.

Thanks folks.

-Justin

–
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

2

On Wed, Feb 29, 2012 at 8:49 PM, Justin Deoliveira <jdeolive@anonymised.com> wrote:

Hi all,

I have been working through the feedback gathered for GSIP 73.

http://geoserver.org/display/GEOS/GSIP+73+-+Workspace+Local+Styles+and+Layer+Groups

From the email exchange earlier this week this the major feedback I mined
out of it:

1. rest api needs to be updated
2. better ui for local workspace stuff, ideally a single global workspace
drop down
3. more care taken when updating the ResourceAccessManager interface
4. ResourceAccessManager might not be the best place for simply filtering
styles and layer groups

(1) has been completed. Will update patch shortly.

Nice

(2) I would like to push off as a future improvement. I thought about it and
I think it represents quite a bit of work, but i do agree it would be a much
better workflow.

I can go for that. Do you mind if we start a parallel, background discussion
on how to best implement that? It may turn out we find a simpler way
to do that, or it could become something we implement in a code sprint.

(3) Added an abstract base class for the ResourceAccessManager that
extensions can extend from, protecting them from future api changes

Nice

(4) This one i am torn on and allow me to explain. I agree that the
ResourceAccessManager should really be used strictly for security, but on
the other hand we currently do use it for filtering components of the
catalog. And the CatalogFilter interface already supports some catalog
components so why not others.

CatalogFilter is a nice general concept, however it is not necessarily
connected to
security.

As previously mentioned for this proposal I had to add a second catalog
wrapper called LocalWorkspaceCatalog, to do some special handling around
local workspace stuff. I could move all the local workspace filtering stuff
there and away from the CatalogFilter interface. But then we would be
duplicating a lot of the stuff done in SecureCatalog to do filtering of the
various catalog contents. This is actually more inline with how the local
workspace stuff was originally implemented but then it was decided that
using the CatalogFilter interface would be a good idea for that.

To decide which way to go I would like to ask a secondary question. Does
having access limits for styles and layer groups make sense, in any context,
not just a workspace local context? If it doesn't then i can remove those
interface and move everything over to the LocalWorkspaceCatalog wrapper.

I can see that as a security concern, yep. For example, some heavy styles
might be available only to certain users for performance reasons,
or some styles might show information that the general public should not see,
or finally some styles could be using attributes that are not allowed
for everybody
to access.

However if those interfaces do make sense then the fact that we use them for
this filtering is really just an implementation detail, and we could
potentally leave things as is now and move them over at a later time.

I'm ok with the changes, what I was trying to point out is that any
change to the
ResourceAccessManager must be thought through also from the point of
view of security, since that's its primary purpose.

Cheers
Andrea

--
-------------------------------------------------------
Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead

Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584 962313
fax: +39 0584 962313
mob: +39 339 8844549

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

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

3

On Sun, Mar 4, 2012 at 1:33 AM, Andrea Aime <andrea.aime@anonymised.com> wrote:

On Wed, Feb 29, 2012 at 8:49 PM, Justin Deoliveira <jdeolive@anonymised.com> wrote:

Hi all,

I have been working through the feedback gathered for GSIP 73.

http://geoserver.org/display/GEOS/GSIP+73±+Workspace+Local+Styles+and+Layer+Groups

From the email exchange earlier this week this the major feedback I mined
out of it:

  1. rest api needs to be updated
  2. better ui for local workspace stuff, ideally a single global workspace
    drop down
  3. more care taken when updating the ResourceAccessManager interface
  4. ResourceAccessManager might not be the best place for simply filtering
    styles and layer groups

(1) has been completed. Will update patch shortly.

Nice

(2) I would like to push off as a future improvement. I thought about it and
I think it represents quite a bit of work, but i do agree it would be a much
better workflow.

I can go for that. Do you mind if we start a parallel, background discussion
on how to best implement that? It may turn out we find a simpler way
to do that, or it could become something we implement in a code sprint.

Certainly. Could indeed be a good topic for code sprint, maybe at foss4gna.

(3) Added an abstract base class for the ResourceAccessManager that
extensions can extend from, protecting them from future api changes

Nice

(4) This one i am torn on and allow me to explain. I agree that the
ResourceAccessManager should really be used strictly for security, but on
the other hand we currently do use it for filtering components of the
catalog. And the CatalogFilter interface already supports some catalog
components so why not others.

CatalogFilter is a nice general concept, however it is not necessarily
connected to
security.

As previously mentioned for this proposal I had to add a second catalog
wrapper called LocalWorkspaceCatalog, to do some special handling around
local workspace stuff. I could move all the local workspace filtering stuff
there and away from the CatalogFilter interface. But then we would be
duplicating a lot of the stuff done in SecureCatalog to do filtering of the
various catalog contents. This is actually more inline with how the local
workspace stuff was originally implemented but then it was decided that
using the CatalogFilter interface would be a good idea for that.

To decide which way to go I would like to ask a secondary question. Does
having access limits for styles and layer groups make sense, in any context,
not just a workspace local context? If it doesn’t then i can remove those
interface and move everything over to the LocalWorkspaceCatalog wrapper.

I can see that as a security concern, yep. For example, some heavy styles
might be available only to certain users for performance reasons,
or some styles might show information that the general public should not see,
or finally some styles could be using attributes that are not allowed
for everybody
to access.

However if those interfaces do make sense then the fact that we use them for
this filtering is really just an implementation detail, and we could
potentally leave things as is now and move them over at a later time.

I’m ok with the changes, what I was trying to point out is that any
change to the
ResourceAccessManager must be thought through also from the point of
view of security, since that’s its primary purpose.

Cool, and indeed good points. So I’ll leave things as is more or less doing the majority of the work in the catalog filters, and possibly move them into the local workspace catalog wrapper at some later date, which should not have any effect on api.

Cheers
Andrea

–

Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead

Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584 962313
fax: +39 0584 962313
mob: +39 339 8844549

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

–
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.