Geoserver 2.0.x does not currently provide an option to restrict WFS
access to certain layers, and at the same time not to others within
the same instance. Let's say I have 3 layers published as WMS, but I
only want 2 also accessible thru WFS. It would be nice to have control
of how layers are exposed in each output format.
A quick workaround would be to set the "Per-Request Feature Limit"
option in the layer's publishing section to "0", but it does not seem
to be applied (if I set any other number it works and returns that
exact number of features). I suppose the "0" value means "no limit",
but it would be nice to actually use it as a real value to restrict
access to that layer's WFS.
I understand this is not the best solution, as it breaks the
Capabilities document, and so on, but it could be a quick fix before
virtual OWS services are implemented (?), which would eventually
provide more control on publishing options.
C
Cristiano Giovando ha scritto:
Geoserver 2.0.x does not currently provide an option to restrict WFS
access to certain layers, and at the same time not to others within
the same instance. Let's say I have 3 layers published as WMS, but I
only want 2 also accessible thru WFS. It would be nice to have control
of how layers are exposed in each output format.
A quick workaround would be to set the "Per-Request Feature Limit"
option in the layer's publishing section to "0", but it does not seem
to be applied (if I set any other number it works and returns that
exact number of features). I suppose the "0" value means "no limit",
but it would be nice to actually use it as a real value to restrict
access to that layer's WFS.
I understand this is not the best solution, as it breaks the
Capabilities document, and so on, but it could be a quick fix before
virtual OWS services are implemented (?), which would eventually
provide more control on publishing options.
The virtual OWS services have been implemented many months ago
on trunk.
We cannot change the meaning of "0" as the lack of a feature limit
because it would break backwards compatibility (so, if we did,
we'd have to call the next GeoServer 3.0), plus a feature limit
would still make the layer available in the capabilities.
What you need is to alter the current security subsystem to care
about the combination of workspace, layer and service.
Alternatively you could help in merging the GEOXACML work, which
first requires to make the security subsystem pluggable (that's
where the help/funding is needed now). And then a good dose of
patience setting up the rules, last time I tried a single line
in the current simple security config file exploded in 100
lines of GEOXACML.
Cheers
Andrea
--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.
On Thu, Aug 26, 2010 at 07:48, Andrea Aime <aaime@anonymised.com> wrote:
Cristiano Giovando ha scritto:
Geoserver 2.0.x does not currently provide an option to restrict WFS
access to certain layers, and at the same time not to others within
the same instance. Let's say I have 3 layers published as WMS, but I
only want 2 also accessible thru WFS. It would be nice to have control
of how layers are exposed in each output format.
A quick workaround would be to set the "Per-Request Feature Limit"
option in the layer's publishing section to "0", but it does not seem
to be applied (if I set any other number it works and returns that
exact number of features). I suppose the "0" value means "no limit",
but it would be nice to actually use it as a real value to restrict
access to that layer's WFS.
I understand this is not the best solution, as it breaks the
Capabilities document, and so on, but it could be a quick fix before
virtual OWS services are implemented (?), which would eventually
provide more control on publishing options.
The virtual OWS services have been implemented many months ago
on trunk.
We cannot change the meaning of "0" as the lack of a feature limit
because it would break backwards compatibility (so, if we did,
we'd have to call the next GeoServer 3.0), plus a feature limit
would still make the layer available in the capabilities.
What you need is to alter the current security subsystem to care
about the combination of workspace, layer and service.
Alternatively you could help in merging the GEOXACML work, which
first requires to make the security subsystem pluggable (that's
where the help/funding is needed now). And then a good dose of
patience setting up the rules, last time I tried a single line
in the current simple security config file exploded in 100
lines of GEOXACML.
Andrea, thanks for the quick reply and for pointing out that virtual
OWS services have already been implemented in trunk. They work as
expected, but still there is no way to control WFS access per layer
just using virtual OWS and data/service security (please correct me if
I'm wrong).
I finally discovered that the trunk version offers cascaded WMS as a
new datastore type. That got me thinking of a workaround using
Mapserver (or another instance of Geoserver) to serve the layer I
don't want exposed as WFS, which is then published through this new
store type on the main OWS.
As for the GEOXACML, unfortunately I am not a developer myself, but
I'd be happy to test any code progress made on this front. I would
also be interested to learn what options are there to fund these type
of improvements.
C