xwss
  1. xwss
  2. XWSS-14

The creation time is ahead of the current time

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Incomplete
    • Affects Version/s: current
    • Fix Version/s: milestone 1
    • Component/s: www
    • Labels:
      None
    • Environment:

      Operating System: Windows XP
      Platform: All

    • Issuezilla Id:
      14

      Description

      Hi,

      my JAX-WS2.1 EA3 WebService and client are using both XWSS 3.
      The WS-Security is configured this way:

      <xwss:SecurityConfiguration dumpMessages="false" xmlns:xwss="http://
      java.sun.com/xml/ns/xwss/config">
      <xwss:RequireUsernameToken passwordDigestRequired="false"
      nonceRequired="true"/>
      </xwss:SecurityConfiguration>

      If i set nonceRequired="false", all is working well.

      It seem's that this bug is somehow related to Bug number 6, but it occurs
      always.

      The exception on the server includes this information:
      xwss.XwsSecurityInterceptor - Could not validate request:
      com.sun.xml.wss.impl.WssSoapFaultException: The creation time is ahead of the
      current time.; nested exception is com.sun.xml.wss.XWSSecurityException:
      com.sun.xml.wss.impl.WssSoapFaultException: The creation time is ahead of the
      current time.

      Is it possible to provide a build which fixed this bug? That would be great.
      Cheers,

      Ingo

        Activity

        Hide
        shyam_rao added a comment -

        I am not able to reproduce this problem. Send me the reproducable testcase.

        Have you written any DefaultTimestampValidator in server-side callback class in
        your sample? If yes, then search for the pattern
        "yyyy-MM-dd'T'HH:mm:ss'.'sss'Z'" and if you find any such pattern then replace
        it with "yyyy-MM-dd'T'HH:mm:ss'.'SSS'Z'". Now Run the sample and see whether it
        passes or not.

        Show
        shyam_rao added a comment - I am not able to reproduce this problem. Send me the reproducable testcase. Have you written any DefaultTimestampValidator in server-side callback class in your sample? If yes, then search for the pattern "yyyy-MM-dd'T'HH:mm:ss'.'sss'Z'" and if you find any such pattern then replace it with "yyyy-MM-dd'T'HH:mm:ss'.'SSS'Z'". Now Run the sample and see whether it passes or not.
        Hide
        shyam_rao added a comment -

        Adding to my previous comment :

        send the complete server side stacktrace.

        Are you using spring framework for client & server side implementation ?

        Show
        shyam_rao added a comment - Adding to my previous comment : send the complete server side stacktrace. Are you using spring framework for client & server side implementation ?
        Hide
        ingo_siebert added a comment -

        Yes, i'm using Spring-WS at server side.
        But S-WS is reusing existing implementations where ever it can so i thought it's
        most likely a XWSS bug as it was before(issue #6). I thought it may slipped in
        again in XWSS3, after it had been fixed in XWSS2.

        I informed Arjen of S-WS and asking if he is using his own timestamp validator.
        Because i'm on a nightly build on S-WS, i haven't the source available at my
        debugger.

        I'll post more if i know more. If possible, i'll create a test case.

        Ingo

        Show
        ingo_siebert added a comment - Yes, i'm using Spring-WS at server side. But S-WS is reusing existing implementations where ever it can so i thought it's most likely a XWSS bug as it was before(issue #6). I thought it may slipped in again in XWSS3, after it had been fixed in XWSS2. I informed Arjen of S-WS and asking if he is using his own timestamp validator. Because i'm on a nightly build on S-WS, i haven't the source available at my debugger. I'll post more if i know more. If possible, i'll create a test case. Ingo
        Hide
        shyam_rao added a comment -

        It was a XWSS bug found in Issue# 6. But now its already fixed from our side a
        couple of months back. So you need to fix the DefaultTimestampValidator
        Implementation in your side.

        I have had a look into Spring-WS's DefaultTimestampValidator implementation
        found at (
        http://static.springframework.org/spring-ws/site/xref/org/springframework/ws/soap/security/xwss/callback/DefaultTimestampValidator.html).
        Is it the same implementation being used by S-WS ?

        In this implementation, you will have to replace
        "yyyy-MM-dd'T'HH:mm:ss'.'sss'Z'" with "yyyy-MM-dd'T'HH:mm:ss'.'SSS'Z'" . That
        would solve the problem.

        Show
        shyam_rao added a comment - It was a XWSS bug found in Issue# 6. But now its already fixed from our side a couple of months back. So you need to fix the DefaultTimestampValidator Implementation in your side. I have had a look into Spring-WS's DefaultTimestampValidator implementation found at ( http://static.springframework.org/spring-ws/site/xref/org/springframework/ws/soap/security/xwss/callback/DefaultTimestampValidator.html ). Is it the same implementation being used by S-WS ? In this implementation, you will have to replace "yyyy-MM-dd'T'HH:mm:ss'.'sss'Z'" with "yyyy-MM-dd'T'HH:mm:ss'.'SSS'Z'" . That would solve the problem.
        Hide
        ingo_siebert added a comment -

        Hi,

        it's really a bug of Spring-WS and not of XWSS. It'll be fixed in the next
        Spring-WS version. Sorry for the inconvenience.

        Ingo

        Show
        ingo_siebert added a comment - Hi, it's really a bug of Spring-WS and not of XWSS. It'll be fixed in the next Spring-WS version. Sorry for the inconvenience. Ingo

          People

          • Assignee:
            xwss-issues
            Reporter:
            ingo_siebert
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: