Re: Created date validation issues in service client with future times - Axis2 1.6.2, Rampart 1.6.2

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 <[email protected]> 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: [email protected]
> To: [email protected]
>
>
> 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
>
>