I managed to answer this one myself, by trolling the Internet and
reading
the Acegi source. The final answer was to create a
RESTfulDefinitionSource.
I used Spring constructor injection to load in the "security
patterns":
<bean id="filterInvocationInterceptor"
class="org.acegisecurity.intercept.web.FilterSecur
ityInterceptor">
<property name="authenticationManager"
ref="authenticationManager"/>
<property name="accessDecisionManager">
<ref local="httpRequestAccessDecisionManager"/>
</property>
<property name="objectDefinitionSource"
ref="filterDefinitionMap" />
</bean>
<bean id="filterDefinitionMap"
class="com.homeaway.hcdata.utils.acegi.RESTfulDefi
nitionSource" >
<constructor-arg type="java.lang.String" >
<value>
/**:GET=ROLE_READER
/**:PUT,DELETE,POST=ROLE_WRITER
</value>
</constructor-arg>
</bean>
The easiest thing was to then delegate within
RESTfulDefinitionSource to a
RESTfulPathBasedFilterInvocationDefinitionMap, which is
essentially a clone of the
PathBasedFilterInvocationDefinitionMap. (But one that takes
into account Http Methods). I would have liked to extend
PathBasedFilterInvocationDefinitionMap, but it is basically
not friendly to subclassing. Although I followed the logic of that
class
almost exactly so that I could be sure that I got things wired
correctly.
It seems that Acegi might consider this form as the default form??
So that patterns like this
/**=ROLE_SUPERVISOR
default to "all methods". But patterns like this are also acceptable;
/**:PUT,DELETE,POST=ROLE_SUPERVISOR
It could be entirely backwards compatible. And Acegi would then
support
REST!!
You might also consider refactoring the
org.acegisecurity.intercept.web
package. It doesn't lend itself well to extension or variation.
Thanks,
-- Chris
On Aug 21, 2007, at 9:20 PM, Chris Berry wrote:
Unfortunately, this package isn't well suited for extension.
I could extend PathBasedFilterInvocationDefinitionMap
but since it provides no way to access requestMap & pathMatcher
I had to duplicate all of that code.
But I could workaround that, what I don't see is how to get around
the
FilterInvocationDefinitionSourceEditor
I want to be able to do something like this:
<bean id="filterInvocationInterceptor"
class="org.acegisecurity.intercept.web.FilterSecurityInterceptor">
<property name="authenticationManager"
ref="authenticationManager"/>
<property name="accessDecisionManager">
<ref local="httpRequestAccessDecisionManager"/>
</property>
<property name="objectDefinitionSource"
ref="filterDefinitionMap" />
</bean>
<bean id="filterDefinitionMap"
class="com.homeaway.hcdata.utils.acegi.RESTfulPathBasedFilterInvocati
onDefinitionMap"
<property name="objectDefinitionSource" >
<value>
CONVERT_URL_TO_LOWERCASE_BEFORE_COMPARISON
PATTERN_TYPE_APACHE_ANT
/**=ROLE_SUPERVISOR
</value>
</property>
</bean>
But I don't see how to accomplish it??
Must I extend FilterInvocationDefinitionSourceEditor ??
I'm no Spring expert, so I'm unclear how the Property Editors get
wired
in...
Thanks,
-- Chris
On Aug 21, 2007, at 7:10 PM, Brian Moseley wrote:
On 8/21/07, Chris Berry <[EMAIL PROTECTED]> wrote:
Anyway, AFAICT, the solution is to provide a custom
FilterInvocationDefinitionSource
I plan to extend PathBasedFilterInvocationDefinitionMap.
[...]
sure, that looks good to me, with the following caveat:
to support http-based protocols that extend the basic method set,
like
webdav with its PROPFIND, PROPPATCH, MKCOL, LOCK etc, and to keep
mapping files brief, it might be handy to be able to configure named
sets of methods on the FilterInvocationDefinitionSource.
perhaps
something like this:
<property name="readMethods"
value="GET,HEAD,OPTIONS,PROPFIND"/>
<property name="writeMethods"
value="POST,PUT,DELETE,PROPPATCH,LOCK"/>
and:
/foo/bar.html:READ_METHODS,WRITE_METHODS=ROLE_FOO
/secure/*:READ_METHODS=ROLE_BAR
/account/something=ROLE_BAR
---------------------------------------------------------------------
----
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]
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
