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