I had to clean it up a little, but it works good now.
-dain
On Sep 27, 2007, at 7:19 PM, David Blevins wrote:
Oh, and Dain, if you can look at the changes I made to the
TomcatSecurityService and verify it's to your liking that'd be
great. I tightened up the code to use the associate/disassociate
methods directly rather than modifying the thread local directly.
That of course means you have to register the subject which also
means creation of a UUID which you mentioned is expensive. I
wasn't sure how often subjects would be changed in that code so it
may be we still want a back door for speed.
Anyway, take a look.
-David
On Sep 27, 2007, at 6:46 PM, David Blevins wrote:
Revised the r579817 revised SecurityService SPI
Put the return value of associate back to void. Added a
counterpart disassociate method that will allow the
SecurityService impl to clear the identity from any thread state.
Disassociate is now called from the EjbRequestHandler in a finally
block after the request takes place.
Added a logout method for future use that will allow the
SecurityService to clear the identity from any longer, non-thread,
caches it may be keeping post-login.
Also added the use of java generics in the SecurityService
interface to show the intended symmetry of the token returned from
login and how this is related to subsequent associate/disassociate
and eventually logout.
A potentially missing method we might add if needed someday is a
method to get the token associated with the current thread from
the SecurityService via a call like getAssociatedIdentity or
something. But we don't need it yet and that information is
available at login and already required for 'associate', not sure
why some code would come in later that wasn't part of the login
and associate process and desire the token which is only
understandable to the SecurityService.
Anyway, heads up on the change.
-David
