Hi Martin
Thanks for your reply. Tried your suggestion but unfortunately no change.
The WSSConfig still has the default value which is used for the
futureTimeToLive check.
Still working on it - any other suggestions gratefully accepted :-)
Cheers
Matt
On 16 August 2012 23:58, Martin Gainty <mgai...@hotmail.com> wrote:
> 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
>
>
