AnsweredAssumed Answered

4.0.d vs 4.2.d SOAP exception

Question asked by bopolissimus on Sep 23, 2013
Latest reply on Sep 25, 2013 by bopolissimus
Hi all,

I am running:

1. Alfresco 4.0.d bundle
2. Alfresco 4.2.d running on Ubuntu Precise LTE and distribution Tomcat7 and OpenJDK7
3. both alfresco instances talk to a distribution postgres 9.1 instance.
4. Moodle and Alfresco servers (test and production) are in the Australia/Melbourne timezone.

We have an Alfresco CE 4.0.d instance which is accessed by the moodle plugin via the SOAP interface.  That works (in the sense that moodle is able to access files on Alfresco, read/update/create).

Recently (in prep for prod upgrade) I upgraded the testing instance to Alfresco CE 4.2.d (via 4.0.e for the activiti schema upgrades).  Moodle accessing 4.2.d via the SOAP interface no longer works correctly.

After some investigation I see that:
  1. Moodle is sending a SOAP request where the created and expires timestamps are 12 hours ahead
     of current time.


  <Timestamp xmlns="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
    <Created>
2013-09-21T14:37:59Z    </Created>
    <Expires>
2013-09-21T15:37:59Z    </Expires>
   </Timestamp>


  2. Strange as the above seems, it *works* with Alfresco 4.0.d.  I'm not sure why that (the
     advancing of the time) is, perhaps something to do with the fact that Melbourne time
     is halfway around the world from Greenwich (I've had to do a similar adjustment to
     LDAP's personDifferentialQuery (see the +1300 below, although this was for Auckland
     time but the reference I saw that suggested this was by someone in Sydney, I think,
     so it may be a general timezone issue when around the world from GMT).

http://forums.alfresco.com/forum/installation-upgrades-configuration-integration/configuration/timezone-issue-ldap-differential

     and my adjustment was:


     ldap.synchronization.personDifferentialQuery=(&(objectclass\=inetOrgPerson)(!(modifyTimestamp<\={0}+1300)))


  3. When I switch over to alfresco 4.2.d on the test server, it receives the same advanced
     timestamps as above, but that then fails with:


AxisFault
faultCode: {http://schemas.xmlsoap.org/soap/envelope/}Server.generalException
faultSubcode:
faultString: WSDoAllReceiver: The timestamp could not be validated
faultActor:
faultNode:
faultDetail:
        {http://xml.apache.org/axis/}stackTrace:WSDoAllReceiver: The timestamp could not be validated
        at org.apache.ws.axis.security.WSDoAllReceiver.invoke(WSDoAllReceiver.java:318)
        at org.apache.axis.strategies.InvocationStrategy.visit(InvocationStrategy.java:32)
        at org.apache.axis.SimpleChain.doVisiting(SimpleChain.java:118)
        at org.apache.axis.SimpleChain.invoke(SimpleChain.java:83)
        at org.apache.axis.strategies.InvocationStrategy.visit(InvocationStrategy.java:32)
        at org.apache.axis.SimpleChain.doVisiting(SimpleChain.java:118)
        at org.apache.axis.SimpleChain.invoke(SimpleChain.java:83)
        at org.apache.axis.handlers.soap.SOAPService.invoke(SOAPService.java:454)
        at org.apache.axis.server.AxisServer.invoke(AxisServer.java:281)
        at org.apache.axis.transport.http.AxisServlet.doPost(AxisServlet.java:699)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:641)
        at org.apache.axis.transport.http.AxisServletBase.service(AxisServletBase.java:327)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:722)
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305)
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
        at org.alfresco.web.app.servlet.GlobalLocalizationFilter.doFilter(GlobalLocalizationFilter.java:61)
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
        at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:224)
        at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:169)
        at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:472)
        at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:168)
        at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:98)
        at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:927)
        at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
        at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:407)
        at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:987)
        at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:579)
        at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:307)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
        at java.lang.Thread.run(Thread.java:724)



Has anyone seen this? (with 4.2.b, 4.2.c, 4.2.d?)  The servers have the same timezones and system time, so it's not likely that that's the issue.  They *are* VMWare machines, so I've also done this test after setting their times to the same value (avoid issues with VMWare clock skew).

Thank you very much for any assistance.

Gerald

Outcomes