[prev in list] [next in list] [prev in thread] [next in thread] 

List:       xmlrpc-user
Subject:    Re: WSSecurityEngine: Invalid timestamp The security semantics of the message have expired
From:       Colm O hEigeartaigh <coheigea () apache ! org>
Date:       2014-05-07 8:49:16
Message-ID: CAB8XdGCFjmSKnDN+4LxbFP4HZFXW5nOyjNv=n8Mprn25N1+VSg () mail ! gmail ! com
[Download RAW message or body]

> Are 'timestampStrict' and 'timeToLive' the relevant properties for
handling such scenarios?

Yes. "timestampStrict" controls whether to throw an exception or not if the
Expires time of the Timestamp is past the current receiving time.
"timeToLive" is the value in seconds that is added on to the Created time
of the Timestamp, which if greater than the current receiving time means it
is also expired. There is also another property "futureTimeToLive", which
is the time in seconds in the future within which the Created time of an
incoming Timestamp is valid. The default is "60".

Colm.


On Tue, May 6, 2014 at 4:51 PM, Giriraj Bhojak <giriraj2k@gmail.com> wrote:

> I found out the clocks are off by more than 5 mins.
> Syncing them fixed the issue. But the clocks might get out of sync again.
> Are 'timestampStrict' and 'timeToLive' the relevant properties for
> handling such scenarios?
> 
> Thanks,
> Giriraj.
> 
> 
> On Tue, May 6, 2014 at 5:03 AM, Colm O hEigeartaigh <coheigea@apache.org>wrote:
> 
> > 
> > The most likely reason is that the local time on the service machine is
> > out by more than 5 minutes. Timezones shouldn't come into it, as the client
> > should be sending the time in UTC format. You can disable this check via a
> > configuration property if necessary.
> > 
> > Colm.
> > 
> > 
> > On Fri, May 2, 2014 at 10:52 PM, Giriraj Bhojak <giriraj2k@gmail.com>wrote:
> > 
> > > Hi Everyone,
> > > 
> > > I am getting following message while receiving a response from the web
> > > service call.
> > > I am not sure what's going on.
> > > 
> > > ID: 1
> > > Response-Code: 500
> > > Encoding: UTF-8
> > > Content-Type: text/xml;charset=UTF-8
> > > Headers: {connection=[close], content-type=[text/xml;charset=UTF-8],
> > > Date=[Fri, 02 May 2014 21:43:39 GMT], Server=[Apache-Coyote/1.1],
> > > transfer-encoding=[chunked]}
> > > Payload: <soap:Envelope xmlns:soap="
> > > http://schemas.xmlsoap.org/soap/envelope/"><soap:Body><soap:Fault><faultcode
> > > xmlns:ns1="
> > > http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">ns1:MessageExpired</faultcode><faultstring>The
> > >  message has expired (WSSecurityEngine: Invalid timestamp The security
> > > semantics of the message have
> > > expired)</faultstring></soap:Fault></soap:Body></soap:Envelope>
> > > 
> > > 
> > > When I test with the web-service client and web service provider
> > > deployed on my machine, everything works fine.
> > > In the above scenario, the web-service client is on one machine and the
> > > web service provider on another machine.
> > > I am trying to find if the provider server is in a different timezone
> > > than the client.
> > > 
> > > But does anyone know what's the issue here?
> > > 
> > > Thanks,
> > > Giriraj.
> > > 
> > 
> > 
> > 
> > --
> > Colm O hEigeartaigh
> > 
> > Talend Community Coder
> > http://coders.talend.com
> > 
> 
> 


-- 
Colm O hEigeartaigh

Talend Community Coder
http://coders.talend.com


[Attachment #3 (text/html)]

<div dir="ltr"><div><div><br>&gt; Are &#39;timestampStrict&#39; and \
&#39;timeToLive&#39; the relevant properties for handling such \
scenarios?<br><br></div>Yes. &quot;timestampStrict&quot; controls whether to throw an \
exception or not if the Expires time of the Timestamp is past the current receiving \
time. &quot;timeToLive&quot; is the value in seconds that is added on to the Created \
time of the Timestamp, which if greater than the current receiving time means it is \
also expired. There is also another property &quot;futureTimeToLive&quot;, which is \
the time in seconds in the future within which the Created time of an incoming \
Timestamp is valid. The default is &quot;60&quot;.<br><br></div>Colm.<br></div><div \
class="gmail_extra"><br><br><div class="gmail_quote">On Tue, May 6, 2014 at 4:51 PM, \
Giriraj Bhojak <span dir="ltr">&lt;<a href="mailto:giriraj2k@gmail.com" \
target="_blank">giriraj2k@gmail.com</a>&gt;</span> wrote:<br> <blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"><div dir="ltr"><div>I found out the clocks are off by more \
than 5 mins.<br></div><div>Syncing them fixed the issue. But the clocks might get out \
of sync again.<br> </div><div>Are &#39;timestampStrict&#39; and &#39;timeToLive&#39; \
the relevant properties for handling such scenarios?<br> \
</div><div><br></div>Thanks,<br>Giriraj.<br></div><div \
class="gmail_extra"><br><br><div class="gmail_quote">On Tue, May 6, 2014 at 5:03 AM, \
Colm O hEigeartaigh <span dir="ltr">&lt;<a href="mailto:coheigea@apache.org" \
target="_blank">coheigea@apache.org</a>&gt;</span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"><div dir="ltr"><div><br></div>The most likely reason is that \
the local time on the service machine is out by more than 5 minutes. Timezones \
shouldn&#39;t come into it, as the client should be sending the time in UTC format. \
You can disable this check via a configuration property if necessary.<br>


<br>Colm.<br></div><div><div><div class="gmail_extra"><br><br><div \
class="gmail_quote">On Fri, May 2, 2014 at 10:52 PM, Giriraj Bhojak <span \
dir="ltr">&lt;<a href="mailto:giriraj2k@gmail.com" \
target="_blank">giriraj2k@gmail.com</a>&gt;</span> wrote:<br>


<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"><div dir="ltr"><div>Hi Everyone,<br><br></div>I am getting \
following message while receiving a response from the web service call.<br>


I am not sure what&#39;s going on.<br><div><div><br>ID: 1<br>Response-Code: \
                500<br>Encoding: UTF-8<br>
Content-Type: text/xml;charset=UTF-8<br>Headers: {connection=[close], \
content-type=[text/xml;charset=UTF-8], Date=[Fri, 02 May 2014 21:43:39 GMT], \
Server=[Apache-Coyote/1.1], transfer-encoding=[chunked]}<br>Payload: \
&lt;soap:Envelope xmlns:soap=&quot;<a \
href="http://schemas.xmlsoap.org/soap/envelope/" \
target="_blank">http://schemas.xmlsoap.org/soap/envelope/</a>&quot;&gt;&lt;soap:Body&gt;&lt;soap:Fault&gt;&lt;faultcode \
xmlns:ns1=&quot;<a href="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" \
target="_blank">http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-sec \
ext-1.0.xsd</a>&quot;&gt;ns1:MessageExpired&lt;/faultcode&gt;&lt;faultstring&gt;The \
message has expired (WSSecurityEngine: Invalid timestamp The security semantics of \
the message have expired)&lt;/faultstring&gt;&lt;/soap:Fault&gt;&lt;/soap:Body&gt;&lt;/soap:Envelope&gt;<br>




<br><br></div><div>When I test with the web-service client and web service provider \
deployed on my machine, everything works fine.<br></div><div>In the above scenario, \
the web-service client is on one machine and the web service provider on another \
machine.<br>



</div><div>I am trying to find if the provider server is in a different timezone than \
the client.<br><br></div><div>But does anyone know what&#39;s the issue \
here?<br><br></div><div>Thanks,<br>Giriraj.<br></div></div></div>



</blockquote></div><br></div><br clear="all"><span class="HOEnZb"><font \
color="#888888"><br></font></span></div></div><span class="HOEnZb"><font \
color="#888888"><span><font color="#888888">-- <br>Colm O hEigeartaigh<br><br> Talend \
Community Coder<br><a href="http://coders.talend.com" \
target="_blank">http://coders.talend.com</a><br>

</font></span></font></span></blockquote></div><br></div>
</blockquote></div><br><br clear="all"><br>-- <br>Colm O hEigeartaigh<br><br>Talend \
Community Coder<br><a href="http://coders.talend.com" \
target="_blank">http://coders.talend.com</a><br> </div>



[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic