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.RESTfulPathBasedFilterInvocatio
nDefinitionMap" >
<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
