Venkat Sonnathi wrote:
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.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?
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=7412&alloc_id=16344&op=click _______________________________________________ Home: http://acegisecurity.sourceforge.net Acegisecurity-developer mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
