On Thu, Aug 26, 2010 at 07:48, Andrea Aime <aa...@opengeo.org> 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 ------------------------------------------------------------------------------ Sell apps to millions through the Intel(R) Atom(Tm) Developer Program Be part of this innovative community and reach millions of netbook users worldwide. Take advantage of special opportunities to increase revenue and speed time-to-market. Join now, and jumpstart your future. http://p.sf.net/sfu/intel-atom-d2d _______________________________________________ Geoserver-users mailing list Geoserver-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-users
