AppModule Security context is not cleaned after releasing

hoanvuphan

Hi all,

I am using ADF 12.1.3, my application have both web application and batch jobs running.

• When batch jobs running, I create new AppModule instance to be used inside the job by calling the code below:
  • Configuration.createRootApplicationModule(AppModuleImpl.DEFINITION_NAME, AppModuleImpl.CONFIGURATION_NAME_INTERFACE);
• After the batch job complete, the AppModule is released in the finally block by calling
  • Configuration.releaseRootApplicationModule(am, false);
• The batch job is scheduled using  commonj.timers.TimerManager api.
• When the job is running, if an entity is updated, the ModifiedBy attribute is set to anonymous automatically, so it's OK

So recent weeks, I am facing a problem that sometimes, the ModifiedBy attribute is set to some users that accessing the application at the same time (or a little bit before) of the batch job running.

It's really weird as it seems the security context in AppModule is not completely cleaned the after releasing. Is it possible? How is it possible?

Is it linked to AppModule pooling or something?

Do you have any idea?

Kind regards,

Vu

Dimitar Dimitrov

Hi,

It depends on the current thread that you invoke your code from. The ApplicationModule gets the authenticated principal from the security context of the thread's ADFContext (ADFContext.getCurrent().getSecurityContext().getUserPrincipal()). ADFContext and its SecurityContext are initialized automatically by various routines depending on the execution context (for example, by ADFBindingFilter or ServletADFFilter in case of a servlet, or oracle.adf.share.security.authentication.JAASAuthenticationService in case of a standalone JavaSE application).

If you cannot find where the authenticated Principal comes from in your case, you can just clear it before getting the ApplicationModule. The method SecurityContext.setPrincipal() is protected, but you can use a hack to clear the Principal:

The authenticated principal is stored within the security context in its internal environment map (under the key Context.SECURITY_PRINCIPAL). In order to clear the authenticated principal you can try something like this:

ADFContext.getCurrent()
    .getSecurityContext()
    .addToEnvironment(Context.SECURITY_PRINCIPAL, null);

Dimitar

P.S. In one of my projects I had to do the opposite - in a WebLogic web service I had to set the authenticated principal into ADFContext (using the authenticated Principal from the web service's context), because web services are not servlets and therefore there was neither ADFBindingFilter nor ServletADFFilter to set it in ADFContext automatically:

   ADFContext.getCurrent()
        .getSecurityContext()
        .addToEnvironment(Context.SECURITY_PRINCIPAL, wsContext.getUserPrincipal());