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.
-David
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
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
!DSPAM:4040,483bad5474851336712104!
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
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
!DSPAM:4040,483bad5474851336712104!
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/](http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/)
_______________________________________________
Geoserver-devel mailing list
[Geoserver-devel@lists.sourceforge.net](mailto:Geoserver-devel@lists.sourceforge.net)
[https://lists.sourceforge.net/lists/listinfo/geoserver-devel](https://lists.sourceforge.net/lists/listinfo/geoserver-devel)
I suspect that I might be providing controversial advice here (plus Im new to the list) but why are you reinventing the wheel with ReST? Using an embedded eXist engine would provide 98.6% of your restful interface requirements, plus 300% additional options. I’m assuming your requirements include resource level permission management similar to a unix file system… This is certainly a can of worms and I’m willing to play devils advocate on behalf of embedded exist, given that it’s an additional library, open source or not. (PS if you keep up with eXist you’ld also know it’s supporting very important ReSTful protocols like Atom Publishing as well as some geo spatial indexing from google-summer-o-code sponsored projects.) I’m not suggesting that an xmldb replace existing datasource support, only that you can use eXist internally in a webapp at runtime in such a way that ReST becomes a much more natural development strategy.
$0.02
Chris Thatcher (And thanks for the awesome software!)
I'm not familiar with eXist; however, it looks like there are a few reasons why it wouldn't work as well as custom Restlets for our needs.
* Not all of the resources we are exposing correlate 1:1 to XML
documents in the Data directory. For example, modifying
featuretype configurations may result in modifications to both a
catalog file and a per-featuretype configuration file. There is
also discussion about unifying the 'coverage/featuretype'
distinction into a more user-friendly 'layer' abstraction.
* We want to allow extensions to add RESTful endpoints to GeoServer
* We provide more than just XML as a representation format. Currently this is just JSON and HTML, but all the apps I know of
that are using GeoServer's REST interfaces right now are using
JSON as preferable to XML (since they are JavaScript apps 
).
If you want to elaborate further on why eXist would do well here, please do. But keep in mind we're doing a bit more than just editing XML documents over the web.
Thanks for the input!
-David Winslow
Chris Thatcher wrote:
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
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
I suspect that I might be providing controversial advice here (plus Im new to the list) but why are you reinventing the wheel with ReST? Using an embedded eXist engine would provide 98.6% of your restful interface requirements, plus 300% additional options. I'm assuming your requirements include resource level permission management similar to a unix file system... This is certainly a can of worms and I'm willing to play devils advocate on behalf of embedded exist, given that it's an additional library, open source or not. (PS if you keep up with eXist you'ld also know it's supporting very important ReSTful protocols like Atom Publishing as well as some geo spatial indexing from google-summer-o-code sponsored projects.) I'm not suggesting that an xmldb replace existing datasource support, only that you can use eXist internally in a webapp at runtime in such a way that ReST becomes a much more natural development strategy.
$0.02
Chris Thatcher (And thanks for the awesome software!)
!DSPAM:4040,483d057a105375332866982!
------------------------------------------------------------------------
-------------------------------------------------------------------------
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/
!DSPAM:4040,483d057a105375332866982!
------------------------------------------------------------------------
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
!DSPAM:4040,483d057a105375332866982!
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
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
!DSPAM:4040,483c1d42258422143011171!