Agreed :)
And thanks!

On 8/23/07, Chris Berry <[EMAIL PROTECTED]> wrote:
> Done
> http://opensource.atlassian.com/projects/spring/browse/SEC-531
> Cheers,
> -- Chris
>
>
> On Aug 23, 2007, at 1:44 PM, Chris Berry wrote:
> Will do.
> It sure would be nice to incorporate this back into Acegi.
> IMHO, REST will (or is ;-) supplant all other web service methodologies.
> Acegi should support it natively.
> I need to soon do the same work for securing methods by Http Method
> Cheers,
> -- Chris
>
>
> On Aug 23, 2007, at 1:16 PM, Ray Krueger wrote:
>
> Nice work Chris, any chance you could open some Jiras on that?
>
> On 8/23/07, Chris Berry <[EMAIL PROTECTED]> wrote:
>
> 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.RESTfulPathBasedFilterInvocationDefinitionMap"
>
>
>     <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
>
>
>
>
> -------------------------------------------------------------------------
> 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
>
>

-------------------------------------------------------------------------
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

Reply via email to