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/
_______________________________________________
Geoserver-devel mailing list
[email protected]
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!)
-------------------------------------------------------------------------
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
