WSE 2.0 SP2 - TimeZone, "Message Expired"

Discussion in 'ASP .Net Web Services' started by Benjamin, Jan 14, 2005.

  1. Benjamin

    Benjamin Guest

    Hi!

    When I change TimeZone (emulating a user on the other side of the globe) my
    webservice returns following exception:

    Microsoft.Web.Services2.Security.SecurityFault
    Message: "Message Expired"
    InnerException.Message: "At least one timestamp has expired."

    Any idea how to make the web service "World-Ready" ?
    Benjamin, Jan 14, 2005
    #1
    1. Advertising

  2. Hi Ben,

    We have reviewed this issue and are currently researching on it. We will
    update you ASAP. Thanks for your patience!

    Kevin Yu
    =======
    "This posting is provided "AS IS" with no warranties, and confers no
    rights."
    Kevin Yu [MSFT], Jan 15, 2005
    #2
    1. Advertising

  3. Benjamin

    [MSFT] Guest

    Hello,

    Can you explain more about how you change the TimeZone in the web method?
    Can you post the code here so that we can know what is going on?

    Thanks,

    Luke
    [MSFT], Jan 17, 2005
    #3
  4. Benjamin

    Benjamin Guest

    I have not done any specific either in the client or web service code about
    Time Zones.
    What I meant with "I change TimeZone" is that I, on my client pc, simply
    open "Control Panel | Date/Time | Time Zone Tab" and changed from "GMT+01:00"
    to "GMT+02:00". The web service is running on a server machine with unchanged
    "GMT+01:00".

    How to setup WSE to handle TimeZone-differences?

    "[MSFT]" wrote:

    > Hello,
    >
    > Can you explain more about how you change the TimeZone in the web method?
    > Can you post the code here so that we can know what is going on?
    >
    > Thanks,
    >
    > Luke
    >
    >
    Benjamin, Jan 18, 2005
    #4
  5. Benjamin

    [MSFT] Guest

    Hello,

    I found a simaliar issue which was resolved by following solution:

    1. Timestamp.TtlInSeconds property. This gets or sets the number of seconds
    after creation that a message is valid. You were setting this in your
    client side code to either 0,1, or -1. This means that when WSE will
    compare the local server time to the expiration time. When you set this to
    -1, you’ll see that the <expiration> tag is not included in the soap
    envelope however it still fails because of item #3 below

    2. <ttlInSeconds> element - This tag you can add to a configuration file to
    specify how long an issued SecurityContextToken security token is valid.

    3. <timeToleranceInSeconds> element - This is what you need to resolve your
    issue. This value specifies the time buffer used by WSE when it compares
    the timestamps for a SOAP message. You use the <timeToleranceInSeconds>
    element when there is a clock difference between the SOAP message sender
    and receiver. WSE uses the <timeToleranceInSeconds> element when it
    compares the current time against the expiration time for all security
    tokens and against the creation time for post-dated security tokens. The
    default time buffer is five minutes. That is, WSE uses the
    <timeToleranceInSeconds> element to determine the time buffer of when a
    security token or SOAP message is valid.

    Solution
    =====================
    To resolve your issue we simply needed to add this <timeToleranceInSeconds>
    element to the configuration file of the client and the web service. For
    the web service you simply modify the web.config file. Here is the relevant
    change that I made to your web.config file that you sent as the repro.

    <microsoft.web.services2>
    <diagnostics />
    <security>
    <timeToleranceInSeconds>660</timeToleranceInSeconds> <!-- 660 = 11
    minutes -->
    </security>
    <tokenIssuer>
    <autoIssueSecurityContextToken enabled="false" />
    <ttlInSeconds>0</ttlInSeconds>
    </tokenIssuer>
    </microsoft.web.services2>

    This would resolve any errors thrown at the server where the client
    expiration (or creation) times are already surpassed. But then you have to
    add this configuration to the client application as the server is sending
    back timestamps of when the messages expire back to the client. For the
    client application you have to add a app.config file that has the following
    data:

    <?xml version="1.0" encoding="utf-8"?>
    <configuration>
    <configSections>
    <section name="microsoft.web.services2"
    type="Microsoft.Web.Services2.Configuration.WebServicesConfiguration,
    Microsoft.Web.Services2, Version=2.0.0.0, Culture=neutral,
    PublicKeyToken=31bf3856ad364e35" />
    </configSections>
    <microsoft.web.services2>
    <diagnostics>
    <trace enabled="true" input="InputTrace.webinfo"
    output="OutputTrace.webinfo"
    />
    </diagnostics>
    <security>
    <timeToleranceInSeconds>660</timeToleranceInSeconds>
    </security>
    </microsoft.web.services2>
    </configuration>


    You can actually use the WSE Configuration Tool to automatically create
    this app.config file and add it to your client solution files. I recommend
    reading up on the WseConfigEditor2.exe tool as documented in the WSE
    documentation.

    Hope this help,

    Luke
    [MSFT], Jan 18, 2005
    #5
  6. Benjamin

    Benjamin Guest

    When testing all your nice suggestions I suddenly made a revolutionary insight.

    All the strange "time zone exception"-behaviour that was the background to
    my problem, is only occuring if I change Time Zone (in Control Panel) when my
    ..NET Windows Form Client is already started.

    If I close down my .NET Windows Form Client, and then change Time Zone (in
    Control Panel) and then restart my .NET Windows Form Client, the client
    always works with any Time Zone setting (without any specific workaround
    coding).

    It seems that .NET saves some variables in some kind of global cache that it
    reuses at all future web service calls. If times differs in that case
    exceptions are raised.

    So in practice there was no problem from the beginning.
    Because it is not a requirement that my .NET Windows Form Client should
    support "changes of Time Zone" WHEN RUNNING the client.

    This experience can be nice to memorize when others run into
    "TimeZone"-problems.

    Many thanks,
    Benjamin
    Benjamin, Jan 18, 2005
    #6
  7. Benjamin

    [MSFT] Guest

    Your suspicion is reasonable. I aslo think it should work in this way.
    Anyway this needs to be confirmed with our production team.

    Thank you for the update.

    Luke
    [MSFT], Jan 19, 2005
    #7
  8. Where is you client code located... messages are created using GMT so they
    are world ready... did you change the time zone in the middle of the request

    "Benjamin" wrote:

    > Hi!
    >
    > When I change TimeZone (emulating a user on the other side of the globe) my
    > webservice returns following exception:
    >
    > Microsoft.Web.Services2.Security.SecurityFault
    > Message: "Message Expired"
    > InnerException.Message: "At least one timestamp has expired."
    >
    > Any idea how to make the web service "World-Ready" ?
    Roland Whitley, Jan 14, 2006
    #8
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. asaf
    Replies:
    3
    Views:
    6,144
    =?ISO-8859-1?Q?Arne_Vajh=F8j?=
    Sep 11, 2006
  2. axrock
    Replies:
    8
    Views:
    952
    Roedy Green
    Mar 25, 2009
  3. RobIsUpside

    Nested install of WSE 2 sp2 fails with error

    RobIsUpside, Jan 19, 2005, in forum: ASP .Net Web Services
    Replies:
    0
    Views:
    301
    RobIsUpside
    Jan 19, 2005
  4. WSE 2.0 - Message Expired

    , Oct 18, 2005, in forum: ASP .Net Web Services
    Replies:
    2
    Views:
    372
  5. Ami
    Replies:
    5
    Views:
    277
Loading...

Share This Page