>-----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 would propose the following: > >- SecurityContext to provide a startRequest() and >finishRequest() method that is called by >HttpSessionContextIntegrationFilter. >- The startRequest() and finishRequest() set >Authentication.isAuthenticated() to false. Do it twice in case >the Authentication is being presented from a remote system (eg >via RMI) which has set the isAuthenticated() to true. >- An AuthenticationProvider may, but is not required to, set >Authentication.isAuthenticated() to true. If it does set it to >true, it means it does not require further callback and the >Authentication can safely be used for the remainder of the >request. AuthenticationProviders should provide a property >setting so this can be switched off (ie they never set the >flag to true) as in special situations (like chained >AuthenticationProviders or a cache-aware ProviderManager) it >might be undesirable. In that case, wouldn't it be better if ProviderManager set this, and ofcourse cache-aware ProviderManager too(if any). >- AbstractSecurityInterceptor honours the >Authentication.isAuthenticated() property by not calling >AuthenticationManager if not required. >AbstractSecurityInterceptor never sets >Authentication.isAuthenticated() (it does at present) >This means there are only two actors changing the >Authentication.isAuthenticated() flag: >HttpSessionContextIntegrationFilter to clear it, and an >AuthenticationProvider to set it. >>You are only considering DAO authentication provider here, how about >>the other providers that do not have caching? >> >Most AuthenticationProvider implementations use caching. At >least the CAS, X.509 and DAO providers do, and they're the >main ones people use. We are using Jaas provider :( >Besides, I was supporting that we should address this issue, >just noting it isn't a critical performance issue at present. >The benefit of these changes is mainly going to be avoiding >unnecessary interaction with collections in ProviderManager >and the various caches, plus providing a request-specific hook >for future expansion. That should improve performance, >although today's collection implementations are fairly well-optimised. > >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 >Acegisecurity-developer@lists.sourceforge.net >https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer > > ------------------------------------------------------- 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 Acegisecurity-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
