On Feb 24, 2009, at 3:11 AM, Jean-Louis MONTEIRO wrote:
As far as I can see, the LocalInitialContext invokes the
SecurityService
login during the context creation.
But I can not see the SecurityService logout call during the logout
(invoked
from close method) invocation of the LocalInitialContext.
Is it a deliberated choice ?
It seems a little stange.
Not sure I follow. If you could elaborate that'd be great.
Moreover, I have a question related to the ClientSecurity usage
inside the
container.
On the deprecated version InitContextFactory, the security identity
was
bound to the current thread (calling associate method from the
security
service). But in the current implementation, the security identity
is bound
to the ClientSecurity object which is static !
From my point of view, it implies we can not use more than one
identity per
JVM even if we instantiate two InitialContext (provided 2 different
credentials).
That's definitely the implication for the static scoped mode. It
would be fantastic if the ClientSecurity code could support more modes
like the ClientSecurity in the remote client can. A thread scoped
option would be great. The ClientSecurity in the core.ivm package is
really just a starter and should be expanded.
I added the static mode per request of a user who was using Swing
which creates a lot of threads to process GUI events.
The code in InitContextFactory is really unsafe as it sets thread
state in the security service but doesn't cleanly remove that state.
Really the security service associate() method should never be called
unless there's a finally block that calls disassociate(). The
security service's job really isn't to track a user session, more to
just give you a security token you can hold for whatever scope you
like and use on your calls. Better to beef up the core.ivm
ClientSecurity to have different ways to track the session, optimally
including some sort of pluggable strategy.
-David
