Details
Description
there's no code to reset ContextManager.currentCaller in the jetty integration. It gets set o.m.j.servlet.WebApplicationHandler.dispatch checking security credentials >>>>>> InternalJAASJettyRealm, and also by JettyEJBWebServiceContext somewhat more directly.
The problem appears to occur when a subject is left on a thread and the thread is used for an unauthenticated ejb web services call. The responsibility for setting the subject on unauthenticated ejb web services calls is too distributed, but what actually sets it is GenericEJBContainer.DefaultSubjectInterceptor, which only installs the defaultSubject if there is no subject already set.
A minimal fix is to set the currentCaller to null if no authentication is needed in JettyEJBWebServiceContext:
if (authenticator != null) {
String pathInContext = org.mortbay.util.URI.canonicalPath(req.getPath());
if (authenticator.authenticate(realm, pathInContext, req, res) == null)
} else
{ //EJB will figure out correct defaultSubject shortly //TODO Need to check that the handler chain will see the correct defaultSubject ContextManager.setCurrentCaller(null); }However, it would be much better to make sure that in addition the subject can't escape back into the calling environment. This can be done easily in JettyEJBWebServiceContext but requires a simple subclass of o.m.j.servletWebApplicationHandler for normal servlet requests.