After a discussion at May 27's GeoServer meeting, it was decided that since REST extensions may allow access to resources beyond those exposed in the configuration API, having a separate configuration system for REST resource permissions is both appropriate and useful. I'll work on making these configurable via the data dir Real Soon Now (tm).
The meeting log is at http://geoserver.org/display/GEOS/2008/05/27 for those interested in the discussion. -David David Winslow wrote: > Andrea Aime wrote: > >> David Winslow ha scritto: >> >>> Hey all, just a heads-up that I caught and fixed a typo in the main >>> security context. If you're using the rest module in community, >>> updating will cause your application to require authentication for >>> non-GET requests. That is, if you are using Restlet to provide web >>> services under the {gs_context}/rest/ path, GET requests are >>> unrestricted while PUT/DELETE/POST requests require authenticating >>> with either ROLE_ADMINISTRATOR or ROLE_AUTHENTICATED. If you would >>> like to adjust these restrictions, you can edit >>> applicationSecurityContext.xml in main. >>> >>> This affects trunk and the 1.6.x branch. >>> >> Nice to have those in place, but imho bad that you need to unpack >> a jar in order to configure those. Any chance we can have a >> rest.properties file (or something like that) in the data directory >> instead? >> Is the configuration done at the resource path level or >> something an "all or nothing"? >> out there. >> Cheers >> Andrea >> >> >> >> > > Yes, it's kind of lame that these need to be configured all in one place > right now. However, I wonder whether it makes sense in the long run to > have per-path restrictions at all. What we really care about securing > is various aspects of the configuration, and data, right? If we allow > accessing these from multiple paths (ie, the RESTful WFS versus the > traditional form, the config interface vs. the config API) then > path-based restrictions are going to be confusing and make it easy to > leave gaping security holes, so maybe it's better to just leave it out > entirely? > > -David > > ------------------------------------------------------------------------- > 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 > > !DSPAM:4040,483c1d42258422143011171! > > ------------------------------------------------------------------------- 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
