Re: [Acegisecurity-developer] (no subject)
That's the correct URL for the core, https://src.springframework.org/svn/spring-security/branches/2.0.x-branch is the url for the whole branch. There's a SSL certificate mismatch - that's probably confusing your client. I use Eclipse and it prompted me to keep the mismatched certificate and I'm able to see the whole repo. -- Burt On Monday 22 December 2008 8:28:24 pm Andrew Wang wrote: Hello, Can somebody tell me how to build acegi? I am trying to follow this link http://static.springframework.org/spring-security/site/building.html Build immediately i found the url is wrong, I use browser to figure out that should be https://src.springframework.org/svn/spring-security/branches/2.0.x-branch/core/ But still svn client can not reach the url, some thing wrong with my svn? What's a proper step by step instruction? Thanks Andrew -- ___ Home: http://acegisecurity.org Acegisecurity-developer mailing list Acegisecurity-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
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] (no subject)
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. For example bean id=filterInvocationInterceptor class=org.acegisecurity.intercept.web.FilterSecurityInterceptor property name=authenticationManager ref=authenticationManager/ property name=accessDecisionManager ref local=httpRequestAccessDecisionManager/ /property property name=objectDefinitionSource value CONVERT_URL_TO_LOWERCASE_BEFORE_COMPARISON PATTERN_TYPE_APACHE_ANT /**=ROLE_ALL /value /property /bean Would need something like this??? POST /items ROLE_WRITER PUT /items/** ROLE_WRITER DELETE /items/** ROLE_WRITER GET /items/** ROLE_READER GET /items ROLE_READER How would I go about this?? Does Acegi somehow understand REST already?? Any suggestions would be greatly appreciated. Thanks, -- Chris 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
Re: [Acegisecurity-developer] (no subject)
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.RESTfulPathBasedFilterInvocationD efinitionMap 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] - 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] (no subject)
Yes, that would work. Thanks.
-tim
Hi Tim
Yes, the design does require the DAO provider know how to interpret
the presented AclObjectIdentity.
As you know, JdbcDaoImpl (and any BasicAclDao for that matter) needs
to be able to create BasicAclEntry[]s in response to the DAO request.
Each BasicAclEntry has getAclObjectIdentity() and
getAclObjectParentIdentity() methods, meaning the BasicAclDao needs to
convert from row-data expressing this information into a new object
instance. So, whilst your proposal caters for object - database
mapping, it doesn't address database - object mapping.
I guess we could offer a pluggable interface within JdbcDaoImpl which
does this conversion. ie:
public interface AclObjectIdentityStringResolver {
public AclObjectIdentity convertToIdentityObject(String identity);
public String convertToIdentityString(AclObjectIdentity
aclObjectIdentity);
}
Would that address your needs?
Ben
---
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
___
Acegisecurity-developer mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
---
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
___
Acegisecurity-developer mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
[Acegisecurity-developer] (no subject)
Thought about posting this in the forum, but thought the dev mailing list would be a better place to bring this up. I've gotten my prototype to successfully perform ACL authentication at the method invocation level. So right now I'm going a bit further beyond the standard ACL implementation given by Acegi to make it fit our needs. One issue I've run into now when Im attempting to use my own AclObjectIdentity. Because while I can set AclManager to use a specific class of AclObjectIdentity, the JdbcDaoImpl implemenation of BasicAclDao specifically checks for AclObjectIdentity to be of NamedEntityObjectIdentity. So basically any attempt to check ACLs on a custom AclObjectidentity will not work w/ jdbcDaoImpl. I see from the code that its necessary to do this because it needs to get values from getId() and getClassname(), which are not part of the interface signature of AclObjectIdentity to create the sql string. However, I would think that any sort of string returned by AclObjectIdentity would work. So I'm wondering if there's a better way this can be handled, like adding a extended interface of AclObjectIdentity that would be called BasicAclObjectIdentity and it would have an additional method such as getNamedEntityString() or something ilke that. And then people could create their own custom implemenations that would return String. Then the JdbcDaoImpl coudl check to ensure that the object passed in implements BasicAclObjectIdentity, instaed of a specific class implementation, which is really not what the Spring people advocate (code against interfaces, not classes). Re-coding the NamedEntityObjectIdentity to use the extended interface, and returning the string to be used in the SQL w/ the interface method would ensure that it would continue working, i think. If I'm missing something - then please do point out what it is. (I realize I can write my own custom DAO implementations to handle this stuff, but would like to extend/use as much acegi-provided code as possible. --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 ___ Acegisecurity-developer mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
[Acegisecurity-developer] (no subject)
Hello ! I am new to this framework, I have changed the default queries in net.sf.acegisecurity.providers.dao.jdbc.jdbcDaoImpl, and now I want to compile the project again. I guess it should be a simple task to use ant build but It seems that with the distribution file acegi-security-0.6-with-dependencies.zip the project.properties and build.properties are missign, so apparently I cannot compile the project. any ideas or any clues I will highly appreciate your response. Regards, Sami Ather -- System Developer Product Development Engineering AUSTAR Communications Pty Ltd Ph : 02 9394 9511 ** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. www.mimesweeper.com ** --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 ___ Acegisecurity-developer mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
Re: [Acegisecurity-developer] (no subject)
[EMAIL PROTECTED] wrote: Hello ! I am new to this framework, I have changed the default queries in net.sf.acegisecurity.providers.dao.jdbc.jdbcDaoImpl, and now I want to compile the project again. I guess it should be a simple task to use ant build but It seems that with the distribution file acegi-security-0.6-with-dependencies.zip the project.properties and build.properties are missign, so apparently I cannot compile the project. any ideas or any clues I will highly appreciate your response. Regards, Sami Ather Hi Sami Apologies for that. It's actually not come up so far, as everyone running builds performs a CVS checkout. I've just made a change to the Ant build release target so it's included in future releases. As for the JdbcDaoImpl, any reason you wouldn't subclass it or use its setMapping() or setQuery() methods? We've designed JdbcDaoImpl to be easily customisable through these extension points, so please let us know if it doesn't meet your needs in some way. Best regards Ben --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 ___ Acegisecurity-developer mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
