Thanks for the reply!
I've been googling for quite a while and haven't come up with too much.
This is a bit odd because REST is quickly becoming The Way.
Acegi is a nice solution because it is entirely Filter based, and
thus, a separate aspect applied externally (via Spring) to the webapp.
And Acegi allows for an easy, transparent upgrade to different
Authorization techniques (e.g. SSO) as the webapp evolves
So I expected to find more interest in REST from the Acegi community??
Anyway, AFAICT, the solution is to provide a custom
FilterInvocationDefinitionSource
I plan to extend PathBasedFilterInvocationDefinitionMap.
And will
1) override getAttributes() which will call lookupAttributes suppling
the HTTP method
2) overload lookupAttributes as lookupAttributes( String url, String
httpMethod)
where the mapping will now look like this::
/foo/bar.html:POST,DELETE=ROLE_FOO (for GET or POST HTTP methods)
/secure/*:GET=ROLE_BAR (only for GET HTTP method)
/account/something=ROLE_BAR (implies all
(Note that this format was suggested in a post by Ben Alex to the
Spring forums)
Does that sound about right??
It sure would be nice if this was the default (with "implies all"
assumed) ;-)
Thanks,
-- Chris
On Aug 21, 2007, at 6:39 PM, Brian Moseley wrote:
On 8/21/07, Chris Berry <[EMAIL PROTECTED]> wrote:
Greetings,
I am trying to set up Acegi (using HTTP BASIC Auth) for a set of
RESTful web
services (implemented using the Atom Publishing Protocol)
And I have the basic setup running.
But REST complicates matters because the exact same URL is used
for "reads"
and "writes", with the HTTP method determining which.
I want to set up Acegi so that it will allow different Roles for
the same
URL but different HTTP Methods.
i've implemented this by providing a custom Voter that checks for a
hard-coded role name for all read methods and a different hard-coded
role name for all write methods. i didn't particularly need flexible
role name configuration, and there's never a case in my application
where a method can signify a read operation on one resource but a
write operation on a different resource (and the only time i can
imagine this is when you're overloading POST), this was good enough.
i'd love to see a better solution baked into the framework.
----------------------------------------------------------------------
---
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a
browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Home: http://acegisecurity.org
Acegisecurity-developer mailing list
Acegisecurity-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
S'all good --- [EMAIL PROTECTED]
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Home: http://acegisecurity.org
Acegisecurity-developer mailing list
Acegisecurity-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
