Re: [Acegisecurity-developer] Question about AbstractSecurityInterceptor
On 5/18/05, Mansoor, Ghazenfer (EDS) [EMAIL PROTECTED] wrote: -Original Message- Mansoor, Ghazenfer (EDS) wrote: How about adding this check at one central place, AuthenticationManager? I am doing this and I do not see any problem. I set the authenticate to true after successful authentication, and check for isAuthentication() before every call. What sets your Authentication.isAuthenticated() back to false at the start of each request? Why should it be set to false at the start of each request? It should be set to false only at the end of each user session. Logout code will set the context to null (Authentication object prior to .9 version) and user no longer have access to Authentication Object. New session will created a new Authentication Object to start. I am also a bit puzzled as to why we should reset the flag at the start of each request? In a typical web app, authentication is done once per session. Any pointers to how SecurityContext is propagated for RMI calls? Regards, --Venkat. --- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_idt12alloc_id344op=click ___ Home: http://acegisecurity.sourceforge.net Acegisecurity-developer mailing list Acegisecurity-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
Re: [Acegisecurity-developer] Suggestion to optimize BasicAclEntryAfterInvocationCollectionFilteringProvider
Hi, Attachments are being removed by mailing list ? On 5/18/05, Paulo Neves [EMAIL PROTECTED] wrote: Hi ben, This morning I get all code from CVS and do my tests. A good improvement, but the similarity of the original execution times between Dianne and Marissa has me confused as to why your results reported a major difference in execution time between them. Well, this occur because Marissa in my other test had access to all contacts, and dianne only have access to 4 or 5 contacts (I change that in code, sorry if I don't sayd that); As an aside, I wouldn't generally be encouraging people to return 10,000 elements inside a Collection and then expect the ACL package to filter out all but 4 or 5 items. That sort of thing is an abuse of an RDBMS platform's inbuilt capabilities! :-) Still, we should aim to optimise the Java code as greatly as possible, so I am happy to explore this benchmarking and squeeze better performance out of it. I agree with you :), but my test only have the purpose to see scalability and optimize any code for extreme situation. And now, my tests that I had done this morning: 1º I change DataSourcePopulator to populate permissions on all contacts to user scott. template.execute(INSERT INTO acl_permission VALUES (null, + i + , 'scott',+permission+);); 2º I run tests and create a table with execution times ( see TemposAcegi.pdf ) Note: To use cache I change applicationContext-common-authorization.xml with following: bean id=aclCacheManager class=org.springframework.cache.ehcache.EhCacheManagerFactoryBean/ bean id=aclCacheBackend class=org.springframework.cache.ehcache.EhCacheFactoryBean property name=cacheManager ref local=aclCacheManager/ /property property name=cacheName valueaclCache/value /property property name=timeToIdle value180/value /property property name=timeToLive value180/value /property property name=maxElementsInMemory value2/value /property /bean bean id=aclCache class=net.sf.acegisecurity.acl.basic.cache.EhCacheBasedAclEntryCache property name=cacheref local=aclCacheBackend//property /bean bean id=basicAclProvider class=net.sf.acegisecurity.acl.basic.BasicAclProvider property name=basicAclDaoref local=basicAclExtendedDao//property property name=basicAclEntryCacheref local=aclCache//property /bean I hope my tests could help code optimization. Thanks, Paulo On 5/18/05, Ben Alex [EMAIL PROTECTED] wrote: Paulo Neves wrote: My suggestion is, if we optimize time to remove domain objects we optimize a lot all process. Hi Paulo To make it easier to discuss and reproduce scalability related issues with the ACL packages, I've modified the Contacts sample to automatically create 1,000 extra Contacts and associated ACL records at startup. The DataSourcePopulator also has a createEntities parameter which can be changed to a larger number. This is now checked into CVS. I had DataSourcePopulator create 10,000 entities, and then I did the following: maven multiwar:multiwar deploy acegi-security-sample-contacts-filter.war to Tomcat 5.5 visit the Contacts home page, then login as Marissa to view her contacts maven -Dusername=marissa -Dpassword=koala -DnrOfCalls=3 run maven -Dusername=dianne -Dpassword=emu -DnrOfCalls=3 run Then I repeated the above, but using your change to CollectionFilterer (of course I had to jar:install from /core firstly). Only HttpInvoker was used (this is now the default for Contacts). Initially it took 12,000 ms for Dianne and 12,047 for Marissa. With your changes it took 10,610 for Dianne and 10,687 for Marissa. A good improvement, but the similarity of the original execution times between Dianne and Marissa has me confused as to why your results reported a major difference in execution time between them. Would you please see if you can reproduce my results and perhaps re-check the original time difference between Dianne and Marissa. As an aside, I wouldn't generally be encouraging people to return 10,000 elements inside a Collection and then expect the ACL package to filter out all but 4 or 5 items. That sort of thing is an abuse of an RDBMS platform's inbuilt capabilities! :-) Still, we should aim to optimise the Java code as greatly as possible, so I am happy to explore this benchmarking and squeee better performance out of it. Cheers Ben --- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_id=7412alloc_id=16344op=click ___ Home:
Re: [Acegisecurity-developer] Suggestion to optimize BasicAclEntryAfterInvocationCollectionFilteringProvider
Paulo Neves wrote: Hi, Attachments are being removed by mailing list ? Hi Paulo I received the PDF attachment with your last message. For the benefit of those who might not have seen it, Paulo's changes resulted in significant optimisation for ACL Collection filtering where the principal has access to a small number of Collection elements relative to the overall Collection size. eg a principal having access to 4 elements whilst there are 10,000 elements in the unfiltered Collection resulted in a significant (better than double) performance improvement. The optimisations provide little improvement when a principal has access to most of the elements in the unfiltered Collection. It's clear these optimisations are desirable and I've committed them to CVS. It's good to see some empirical support for changes of this nature. Further optimisations are most welcome. Best regards Ben --- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_id=7412alloc_id=16344op=click ___ Home: http://acegisecurity.sourceforge.net Acegisecurity-developer mailing list Acegisecurity-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
Re: [Acegisecurity-developer] Question about AbstractSecurityInterceptor
Venkat Sonnathi wrote: I am also a bit puzzled as to why we should reset the flag at the start of each request? In a typical web app, authentication is done once per session. Any pointers to how SecurityContext is propagated for RMI calls? I agree, it shouldn't be required. The net.sf.acegisecurity.context.rmi package propagates a SecurityContext from the client-side to the server-side. The HttpSessionContextIntegrationFilter should not used in such deployments, and therefore HttpSessionContextIntegrationFilter will not need to reset the flag at the start of each request. In relation to your other email, I don't see the value of ProviderManager setting the flag. Doing so would means each AuthenticationProvider implementation cannot make its own decision as to whether or not the Authentication should be treated as valid for the remainder of the request. For consistency with caching, I believe the setting of the flag should occur at the AuthenticationProvider level as it improves the prospects of as yet unknown authentication systems working correctly with Acegi Security. Do you have a specific reason why you'd prefer the ProviderManager set the flag? Best regards Ben --- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_id=7412alloc_id=16344op=click ___ Home: http://acegisecurity.sourceforge.net Acegisecurity-developer mailing list Acegisecurity-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
Re: [Acegisecurity-developer] runas without authentication
Brian Moseley wrote: Brian Moseley wrote: that sounds right. i don't have any need for access control on this operation, so it looks like i can simply use anonymous authen and then have my jackrabbit access manager use an AuthenticationTrustResolver to see if the Authentication is anonymous. i think that will work. thanks! following up on this... i enabled both anonymous authentication and run-as for my user account signup operation (i need run-as because my jcr repository access manager requires a user account with the root role to perform this particular operation). this setup works fine, but as soon as the user has signed up for his account, he has to explicitly log in to that account. I would probably try to avoid doing the run-as replacement, as it is a little challenging to overcome the issue you've described without creating the user an entirely different way or exposing an internal token used by AbstractSecurityInterceptor (which I would rather not do, as it could pose a lot of problematic behavior if misunderstood/misused). Have you considered using a different FilterChainProxy for the sign-up URL? That different chain could use a different AnonymousProcessingFilter bean that grants the necessary root role that the JCR requires. This would avoid the need to perform run-as replacement and overcome the central problem of modifying the SecurityContextHolder so that it is stored in the HttpSession at the end of the request. Incidentally, I thought you were doing WebDAV stuff with JCR. If so, WebDAV clients are meant to use digest authentication which is nice and convenient as there's no HttpSession required. Best regards Ben --- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_id=7412alloc_id=16344op=click ___ Home: http://acegisecurity.sourceforge.net Acegisecurity-developer mailing list Acegisecurity-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
Re: [Acegisecurity-developer] runas without authentication
Ben Alex wrote: I would probably try to avoid doing the run-as replacement, as it is a little challenging to overcome the issue you've described without creating the user an entirely different way or exposing an internal token used by AbstractSecurityInterceptor (which I would rather not do, as it could pose a lot of problematic behavior if misunderstood/misused). right, that's exactly what i thought. Have you considered using a different FilterChainProxy for the sign-up URL? That different chain could use a different AnonymousProcessingFilter bean that grants the necessary root role that the JCR requires. This would avoid the need to perform run-as replacement and overcome the central problem of modifying the SecurityContextHolder so that it is stored in the HttpSession at the end of the request. hm, no, i hadn't thought of doing that. i'll see if that works, thanks. Incidentally, I thought you were doing WebDAV stuff with JCR. If so, WebDAV clients are meant to use digest authentication which is nice and convenient as there's no HttpSession required. i am, but this is for the web user interface that lets people sign up for accounts on the server and so forth. --- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_id=7412alloc_id=16344op=click ___ Home: http://acegisecurity.sourceforge.net Acegisecurity-developer mailing list Acegisecurity-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
