Hi Matt-
instead of setting final attributes of final class
org.apache.ws.security.handler.WSHandlerConstants via WSS4J
what happens if you set org.apache.axis2.Constants TIMOUT attribute such as
serviceStub._getServiceClient().getOptions().setProperty(
Constants.Configuration.CONFIG_CONTEXT_TIMOUT_INTERVAL, "60");
in your Axis Client code?
Martin
______________________________________________
Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité
Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger
sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung
oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich dem
Austausch von Informationen und entfaltet keine rechtliche Bindungswirkung.
Aufgrund der leichten Manipulierbarkeit von E-Mails koennen wir keine Haftung
fuer den Inhalt uebernehmen.
Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le
destinataire prévu, nous te demandons avec bonté que pour satisfaire informez
l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci est
interdite. Ce message sert à l'information seulement et n'aura pas n'importe
quel effet légalement obligatoire. Étant donné que les email peuvent facilement
être sujets à la manipulation, nous ne pouvons accepter aucune responsabilité
pour le contenu fourni.
Date: Thu, 16 Aug 2012 18:53:24 +1000
Subject: Created date validation issues in service client with future times -
Axis2 1.6.2, Rampart 1.6.2
From: mfle...@gmail.com
To: java-user@axis.apache.org
Hey all
Hopefully someone has encountered this. Since upgrading to Axis2 1.6.2/Rampart
1.6.2 we have been having a problem with timestamp validation (on the client
side). We are using WSDL2Java to generate a stub and using that to call the
web service. We upgraded from 1.5.3, where we had no problem.
The issue is that the clock on the web service side seems to be a couple of
minutes ahead. The timestamp then fails validation due to a default 60 second
futureTimeToLive. I traced through the source, and this is happening in
org.apache.ws.security.message.token.Timestamp.verifyCreated - the check code
is below.
if (futureTimeToLive > 0) { validCreation.setTime(currentTime +
((long)futureTimeToLive * 1000L));}// Check to see if the created time is in
the future
if (createdDate != null && createdDate.after(validCreation)) { ... return
false;}
So this is fair enough I thought - I just need to increase futureTimeToLive
from the default 60. However I have been unable to do this.
I have tried using setProperty(WSHandlerConstants.TTL_FUTURE_TIMESTAMP, "value
here") on the service client options. I wasn't surprised that this didn't work.
I next tried setting timestampMaxSkew on the RampartConfig. I thought this
might work. I can see it in the RampartMessageData when I trace the code, but
as soon it swaps over to using the Wss4j stuff
(org.apache.ws.security.handler.RequestData), the WSSConfig values are all
default.
So I may be missing the obvious, but does anyone know how to set the
timeStampFutureTTL value in the WSSConfig to enable future Created dates to get
through?
I should mention this is all being done dynamically through code.
Thanks in advance. I have spent a lot of time on what is essentially a simple
client :)Matt
