[Geoserver-devel] Process selection landed on trunk

Makes sense. Thanks for the background, Andrea.

On Tue, Aug 14, 2012 at 12:38 PM, Andrea Aime <andrea.aime@anonymised.com> wrote:

On Tue, Aug 14, 2012 at 8:42 PM, Martin Davis <mdavis@anonymised.com> wrote:

Nice - the best of both worlds!

No surprise, I like the idea of persisting to a simple rule file. Various reasons, a primary one being that it follows the design of the current security subsystem.

And if there’s no resources to develop the UI right now, the file can easily be used on its own directly. 8^)

Sigh, I actually have problems with this as well.

Yes, the old security subsystem was created based on simple property files. The current
one is based on a set of xml ones instead, have a look.

The reason for property files was that there was no money to write a UI back at the time.
And there are still some modules using a simple property or XML file.

The main problem with these is that they play completely outside of the GeoServer configuration
subsystem, in particular:

  • they have no REST counterpart
  • they don’t respond to reload/reset events
  • they make people use the one and only way of configuring GeoServer we repeated for years
    and years is not supported: direct editing of the configuration files on disk
    (GeoServer is not Mapserver, remember?)

The way I’ve just setup the filters instead sticks them into the WPSInfo, which means they
should be editable using the new service configuration subsystem that Juan rolled which…
uh, still does not have the rest resources for WPS… whatever, it should be easy to add.

What I’m trying to say is that the GeoServer configuration should be playing as a single
whole instead of being scattered between files you should not edit and others that
you are forced into editing, as a result it should all be XML.

I can understand adding a extra minor plugin, but this is a major service that I hope
to be able to have as part of core by 2.3.0, so it should try hard to play by the same
rules as the other major services.

Cheers

Andrea

==
Our support, Your Success! Visit http://opensdi.geo-solutions.it for more information.

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
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://twitter.com/geosolutions_it


Martin Davis
OpenGeo - http://opengeo.org
Expert service straight from the developers.

Sorry for the extremely late sounding in on this thread, but I came across it and have a few thoughts.

First off, great work on this initial implementation Andrea. I just tried it out with a nightly from master, and it’s cool to have the capability to turn things off. Realizing that I’m not talking about allocating any resources to this right now I wanted to recognize that what’s there already is awesome.

I like David’s UI idea a lot, but agree with all of Andrea’s concerns about the backend ‘text’ file. We need to continue to think about the scalable backend that will persist things in different ways. Would be nice though if we could come up with more ‘hackable’ conventions though, where the file that gets saved to disk or persisted as a row in a database table could be easy to modify. But that’s probably too much to ask for right now.

One thing though, has there been any thought about incorporating the ability to turn on/off processes to the security system? I could see it being nice to be able to give more trusted ‘power users’ more access to all the processes, and making to so by default a typical user doesn’t get access to real WPS processes. Justin also had a nice idea to use WFS 2.0 StoredQueries similar to how Rendering Transformations work, as a hook in to WPS. That could be the only way to expose processes to generic users, as it would also tie the process to a particular featureType, instead of opening up processes that could be light on some featureTypes but really heavy on a polygon layer with thousands of points in each poly.

I’m also thinking about how we want to evolve to a multi-tenancy architecture, with different users getting different capabilities documents. Virtual Services is the path there now. Would the next step be to make it so each virtual service can enable/disable different processes? In a multi-tenant environment where users could upload all kinds of different layers I feel like we probably need to think more about providing the ability to put caps on long running processes instead of a binary on/off distinction.

Anyways, apologies for the bit of bikeshedding, I’ve got no great answers. But just wanted to think ahead to some of the places I think we’ll be pushed as processing becomes popular.

C

On Tue, Aug 14, 2012 at 5:04 PM, Martin Davis <mdavis@anonymised.com> wrote:

Makes sense. Thanks for the background, Andrea.

On Tue, Aug 14, 2012 at 12:38 PM, Andrea Aime <andrea.aime@anonymised.com> wrote:

On Tue, Aug 14, 2012 at 8:42 PM, Martin Davis <mdavis@anonymised.com> wrote:

Nice - the best of both worlds!

No surprise, I like the idea of persisting to a simple rule file. Various reasons, a primary one being that it follows the design of the current security subsystem.

And if there’s no resources to develop the UI right now, the file can easily be used on its own directly. 8^)

Sigh, I actually have problems with this as well.

Yes, the old security subsystem was created based on simple property files. The current
one is based on a set of xml ones instead, have a look.

The reason for property files was that there was no money to write a UI back at the time.
And there are still some modules using a simple property or XML file.

The main problem with these is that they play completely outside of the GeoServer configuration
subsystem, in particular:

  • they have no REST counterpart
  • they don’t respond to reload/reset events
  • they make people use the one and only way of configuring GeoServer we repeated for years
    and years is not supported: direct editing of the configuration files on disk
    (GeoServer is not Mapserver, remember?)

The way I’ve just setup the filters instead sticks them into the WPSInfo, which means they
should be editable using the new service configuration subsystem that Juan rolled which…
uh, still does not have the rest resources for WPS… whatever, it should be easy to add.

What I’m trying to say is that the GeoServer configuration should be playing as a single
whole instead of being scattered between files you should not edit and others that
you are forced into editing, as a result it should all be XML.

I can understand adding a extra minor plugin, but this is a major service that I hope
to be able to have as part of core by 2.3.0, so it should try hard to play by the same
rules as the other major services.

Cheers

Andrea

==
Our support, Your Success! Visit http://opensdi.geo-solutions.it for more information.

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
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://twitter.com/geosolutions_it


Martin Davis
OpenGeo - http://opengeo.org
Expert service straight from the developers.


Live Security Virtual Conference
Exclusive live event will cover all the ways today’s security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/


Geoserver-devel mailing list
Geoserver-devel@anonymised.comsts.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

On Wed, Sep 5, 2012 at 11:26 PM, Chris Holmes <cholmes@anonymised.com> wrote:

Sorry for the extremely late sounding in on this thread, but I came across it and have a few thoughts.

First off, great work on this initial implementation Andrea. I just tried it out with a nightly from master, and it’s cool to have the capability to turn things off. Realizing that I’m not talking about allocating any resources to this right now I wanted to recognize that what’s there already is awesome.

I like David’s UI idea a lot, but agree with all of Andrea’s concerns about the backend ‘text’ file. We need to continue to think about the scalable backend that will persist things in different ways. Would be nice though if we could come up with more ‘hackable’ conventions though, where the file that gets saved to disk or persisted as a row in a database table could be easy to modify. But that’s probably too much to ask for right now.

One thing though, has there been any thought about incorporating the ability to turn on/off processes to the security system? I could see it being nice to be able to give more trusted ‘power users’ more access to all the processes, and making to so by default a typical user doesn’t get access to real WPS processes. Justin also had a nice idea to use WFS 2.0 StoredQueries similar to how Rendering Transformations work, as a hook in to WPS. That could be the only way to expose processes to generic users, as it would also tie the process to a particular featureType, instead of opening up processes that could be light on some featureTypes but really heavy on a polygon layer with thousands of points in each poly.

Security was certainly in my mind when I was working on this, the ProcessFilter interface that I rolled allows any security subsystem to implement and plug-in an implementation that:

  • shaves off processes depending on the current user
  • alters the user perception of parameters, maybe leaving some out and defaulting their value, or checking some conditions on them such
    as value ranges and the like

The interface thus covers process filtering and security, but when considering it I also took into account other potential needs:

  • internationalize the title and description of processes and parameters without having to touch the code
  • override the existing process metadata, maybe someone integrating GeoServer in their own infrastructure might want to
    change process names and namespace

I’m also thinking about how we want to evolve to a multi-tenancy architecture, with different users getting different capabilities documents. Virtual Services is the path there now. Would the next step be to make it so each virtual service can enable/disable different processes? In a multi-tenant environment where users could upload all kinds of different layers I feel like we probably need to think more about providing the ability to put caps on long running processes instead of a binary on/off distinction.

Workspace wise, same as above, just implement the above interface taking into account the current workspace limitations.

Putting constraint on resources and time used was another concern for sure, while some of it can be addressed by ProcessFilter
I believe it would have been better served by a dedicated interface. I started a discussion on the topic when I was working on
process filtering but eventually run out of time before the discussion could be completed

Cheers
Andrea

==
Our support, Your Success! Visit http://opensdi.geo-solutions.it for more information.

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
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://twitter.com/geosolutions_it