4.0.d vs 4.2.d SOAP exception

[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/timez...

     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

[bopolissimus]

After some poking with SoapUI I determined that 4.0.d was very forgiving of the timestamps in the security header.  4.0.d was validating the timestamp format but not the values.  So it would accept timestamps 24 hours in the future for created and 25 hours in the future for expires.

4.2.d does validate the timestamp against the time on the alfresco server (converted to GMT) so the moodle plugin's naive time adjustments don't work.

Solution is to sync the moodle and alfresco servers to NTP, remove the moodle plugin's +24 and +25 hour adjustments (adjust expires to 1 hour ahead or other acceptable interval) and have the moodle plugin convert the localtime to GMT correctly.