Re: [Acegisecurity-developer] (no subject)
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:
Re: [Acegisecurity-developer] (no subject)
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
Re: [Acegisecurity-developer] (no subject)
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.RESTfulPathBasedFilterInvocat ionDefinitionMap 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
Re: [Acegisecurity-developer] (no subject)
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/
[Acegisecurity-developer] session manager
hello everyone my problem is that i need to invalidate a session by sessionid my answer is the following when i call a method SessionRegistryImpl.removeSessionInformation( sessionId ) this cause that the other user who was logged in the system and have this session id to loggoff?? thanks winmail.dat- 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
Re: [Acegisecurity-developer] session manager
ok, the way to invalidate a session by sessionid should be following add *HttpSessionEventPublisher* add *ConcurrentSessionFilter* into filter chain invoke method *SessionRegistryImpl.getSessionInformation(String sessionId).expireNow()* ** - 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
