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