Luca Morandini ha scritto: > Andrea Aime wrote: >> Questions/comments/feedback welcome. It would be nice to be able to vote >> on this in next week IRC meeting. > > Very well done: pretty simple and clear. > I haven't seen layer creation/erasing: is it supposed to be done by > admin only ?
Good question. Layer creation and erasing as GeoServer stands today are more like layer registering and un-registering, that is, you don't really create the underlying feature type, you just find it and make it available. The current UI does not operate against the actual catalog, but against a set of xxxConfig objects representing the current state of the "unsaved" configuration. Applying security there too, also considering that they are going the way of the Dodo after GeoServer 1.7.0, seems like a waste of time... > Another nitpick: does this proposal lend itself well to the RESTful > Admin API ? What about writing down a draft for this portion of the API ? RESTFul admin will probably have its own way to identify resources and security will be probably integrated into it by adding a "security" sub-resources to each restful element. If you want to think about it in terms of the current security property files, it will be something like /path/to/resource.operation=role1,role2,... where operation is POST/PUT/DELETE and so on... > Moreover, what about extending it to cover processing as well ? Good question, but I don't have an answer. Processing will be affected by service and data security levels, but if you're thinking of securing certain algorithms or securing ways to persistently store results of computations back in GeoServer, then yes, we'll need ways to handle that. How exactly I don't know, there is nothing in the current GeoServer catalog API that allows for real creation of a new feature type, and I believe there won't be for quite some time. Even the WPS spec is setup so that the results can be stored, but only to make the process request asynch. From the WPS spec, page 42: "If storeExecuteResponse is --true? (see Table 50), then the execute response document shall be stored at a web accessible URL." This is just like WCS GetCoverage, you can ask the coverage to be stored, but that only means the server will give you an URL to retrieve it later, not that the resulting coverage will be registered into the server as a new layer. I definitely see the interest in being able to actually register the results as new layer that can be then used by the other OGC services, but that's beyond the WPS spec. > I mean, if I have read-only access to two raster datasets and I want to > generate a third one based on map algebra, I should be able to create a > new raster dataset, right ? How can the ACL express that ? > > Hmmm... this last requirement may complicate matters considerably > though, just look at the XML Schema for Access Control List by OASIS: > http://docs.oasis-open.org/xacml/2.0/access_control-xacml-2.0-rbac-profile1-spec-os.pdf Yeah, it's out of scope for this iteration. This improvement is funded, but we have funding only to cover only vector data and only OGC services. I've included coverages in the proposal because that will not require much extra effort, what you're proposing is definitely out of the resources I can allocate. Cheers Andrea ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Geoserver-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geoserver-devel
