Hi Ben, On 5/19/05, Ben Alex <[EMAIL PROTECTED]> wrote: > 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.
Would this change be in the next release? I would be glad to help if you want. > > 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? > This is was commented by Mansoor. I agree with you - ProviderManager is the not right place for this. 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_idt12&alloc_id344&op=click _______________________________________________ Home: http://acegisecurity.sourceforge.net Acegisecurity-developer mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
