Authentication problems when using ApplicationContext

As we transition to the new Hyland Community, some post links may be temporarily disrupted as we finalize redirects. We apologize for the inconvenience and are working to resolve this as quickly as possible. Details.

mnybon

Hello everyone.

I am trying to create a model2java code generator for the Alfresco model.xml files. Everything was going a-ok until i ran into the problem of actually getting hold of Alfresco types outside the normal bean bootstrapping.

Basically I need to get hold of both the NodeService(at least only the NodeService for now) and whatever security context is currently at play.

I am trying to get hold of the NodeService around the normal bean.xml heirachy of Alfresco by using

...

import org.alfresco.util.ApplicationContextHelper;
import org.springframework.context.ApplicationContext;

...

ApplicationContext context = ApplicationContextHelper.getApplicationContext();

NodeService ns = context..getBean(ServiceRegistry.class).getNodeService();

List<StoreRef> refs = ns.getStores();

But in my unit test which extends BaseWebScriptTest I run into the follwing exception:

net.sf.acegisecurity.AuthenticationCredentialsNotFoundException: A valid SecureContext was not provided in the RequestContext
    at net.sf.acegisecurity.intercept.AbstractSecurityInterceptor.credentialsNotFound(AbstractSecurityInterceptor.java:481)
    at net.sf.acegisecurity.intercept.AbstractSecurityInterceptor.beforeInvocation(AbstractSecurityInterceptor.java:359)
    at net.sf.acegisecurity.intercept.method.aopalliance.MethodSecurityInterceptor.invoke(MethodSecurityInterceptor.java:77)
    at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
    at org.alfresco.repo.security.permissions.impl.ExceptionTranslatorMethodInterceptor.invoke(ExceptionTranslatorMethodInterceptor.java:46)
    at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
    at org.alfresco.repo.audit.AuditMethodInterceptor.invoke(AuditMethodInterceptor.java:159)
    at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
    at org.alfresco.repo.transaction.RetryingTransactionInterceptor$1.execute(RetryingTransactionInterceptor.java:79)
    at org.alfresco.repo.transaction.RetryingTransactionHelper.doInTransaction(RetryingTransactionHelper.java:457)
    at org.alfresco.repo.transaction.RetryingTransactionInterceptor.invoke(RetryingTransactionInterceptor.java:69)
    at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
    at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
    at com.sun.proxy.$Proxy19.getStores(Unknown Source)

After that i found a suggestiong about using AuthenticationUtil as such:

List<StoreRef> refs = AuthenticationUtil.runAs(new AuthenticationUtil.RunAsWork< List<StoreRef>>()
         {
            public  List<StoreRef> doWork() throws Exception
            {
              

                  ApplicationContext context = ApplicationContextHelper.getApplicationContext();

                  NodeService ns = context..getBean(ServiceRegistry.class).getNodeService();

                  return ns.getStores();

               
            }
         }, AuthenticationUtil.getSystemUserName());

But I get the exact same exception.

I would very much appreciate some help firstly in understanding if I am doing something wrong and I have to somehow pass the SecurityContext along manually, and how to get execute code as a system-user or some other priviledged user during unit-testing.

afaust

As already discussed on the IRC #alfresco channel, you should not be using ApplicationContextHelper to obtain an application context. It will never be the same application context as used inside a running Alfresco instance nor the same as used in the BaseWebScriptTest class. Preferably, you NEVER use an application context to obtain any beans, relying instead on regular Spring dependency injection and - in your case - passing along any dependencies from a controlled bean to any runtime instances of node wrappers that you create.