We can certainly hack up something in this regard.
Quick question, what kind of security tracking would be good for you?
I.e. are we talking concurrent users or one user at a time?
We've got some code in the openejb-client package that's pretty useful
for switching to different modes of tracking the user and I was just
thinking just the other day that it wouldn't be a bad idea to port it
to the "server side" as well for embedded scenarios.
Also, I assume this is sort of wrapped up in the other two security
related posts. If not, let me now if there's something more specific
I should be looking at there.
-David
On Aug 7, 2008, at 10:24 AM, Sami Jaber wrote:
Hello all (once more :-)),
After the deployments.ear property and the custom ObjectInputStream,
I have
found another issue which is IMHO more annoying, maybe a structural
design
problem that David will resolve for sure ;-).
I have a pretty big Swing Application that relies on OpenEJB over a
remote
mode (integration platform) and local mode (dev platform).
After digging into the openejb source code (I find them really well
coded
btw), it appear that over LocalInitialContextFactory, the user context
(security, tx, ...) is hold on the ThreadLocal. Not sure but it
seems to be
done in the ClientSecurity.java class thru this code :
public static void login(String username, String password, boolean
threadScoped) throws FailedLoginException {
Object clientIdentity = directAuthentication(username,
password,
server);
if (threadScoped) {
threadClientIdentity.set(clientIdentity);
} else {
staticClientIdentity = clientIdentity;
}
identityResolver = new SimpleIdentityResolver();
}
The problem is that with Swing Application (or any multi-threaded
front-end), you cannot assume that the thread that initiates the new
InitialContext() is the one that will be used to lookup. In my case
I have
implemented (as every smart boy ;-)) a smart proxy pattern which
consist in
keeping the context in a singleton and reusing it between calls. The
issue
is that the lookup is made inside a Swing Action, the Event Thread
Dispatcher raises a new Thread and all credential information are
lost.
That's why in my previous message, I told you that I get randomly
"guest" as
the getCallerPrincipal().
The fix would have been to instantiate a new InitialContext for every
lookup, but not only it kills the performance but you get also an
error
message saying that you cannot assign twice the ThreadLocal.
The last solution that works for me is to write that code for each
lookup,
this is ugly but it does the job :
public static void setInitialContext()
{
try
{
context = new InitialContext(env);
}
catch (Exception e)
{
// if TLS exists Ignore the exception, otherwise, it will set
a new
one in the current thread
}
}
David ?
Sami
