Azure-sdk-for-java: [BUG] Signature does not match when accepting a marketplace ordering agreement

Created on 7 Nov 2019  Â·  13Comments  Â·  Source: Azure/azure-sdk-for-java

Describe the bug

Before using a marketplace Azure VM image, you need to accept its agreement terms. This can be done using the cli, which uses in background the API:

az vm image terms accept -p $publisher -f $offer --plan $sku

The Java SDK uses the same API, but end up with a failure.

Exception or Stack Trace

Exception in thread "main" com.microsoft.azure.management.marketplaceordering.v2015_06_01.ErrorResponseException: Status code 400, {"error":{"code":"BadRequest","message":"Signature does not match. Please request terms again and request acceptance."}}
    at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
    at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
    at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
    at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
    at com.microsoft.rest.ServiceResponseBuilder.build(ServiceResponseBuilder.java:122)
    at com.microsoft.azure.AzureResponseBuilder.build(AzureResponseBuilder.java:56)
    at com.microsoft.azure.management.marketplaceordering.v2015_06_01.implementation.MarketplaceAgreementsInner.createDelegate(MarketplaceAgreementsInner.java:281)
    at com.microsoft.azure.management.marketplaceordering.v2015_06_01.implementation.MarketplaceAgreementsInner.access$100(MarketplaceAgreementsInner.java:40)
    at com.microsoft.azure.management.marketplaceordering.v2015_06_01.implementation.MarketplaceAgreementsInner$5.call(MarketplaceAgreementsInner.java:268)
    at com.microsoft.azure.management.marketplaceordering.v2015_06_01.implementation.MarketplaceAgreementsInner$5.call(MarketplaceAgreementsInner.java:264)
    at rx.internal.operators.OnSubscribeMap$MapSubscriber.onNext(OnSubscribeMap.java:69)
    at retrofit2.adapter.rxjava.CallArbiter.deliverResponse(CallArbiter.java:120)
    at retrofit2.adapter.rxjava.CallArbiter.emitResponse(CallArbiter.java:102)
    at retrofit2.adapter.rxjava.CallExecuteOnSubscribe.call(CallExecuteOnSubscribe.java:46)
    at retrofit2.adapter.rxjava.CallExecuteOnSubscribe.call(CallExecuteOnSubscribe.java:24)
    at rx.Observable.unsafeSubscribe(Observable.java:10327)
    at rx.internal.operators.OnSubscribeMap.call(OnSubscribeMap.java:48)
    at rx.internal.operators.OnSubscribeMap.call(OnSubscribeMap.java:33)
    at rx.internal.operators.OnSubscribeLift.call(OnSubscribeLift.java:48)
    at rx.internal.operators.OnSubscribeLift.call(OnSubscribeLift.java:30)
    at rx.Observable.unsafeSubscribe(Observable.java:10327)
    at rx.internal.operators.OnSubscribeMap.call(OnSubscribeMap.java:48)
    at rx.internal.operators.OnSubscribeMap.call(OnSubscribeMap.java:33)
    at rx.Observable.unsafeSubscribe(Observable.java:10327)
    at rx.internal.operators.OnSubscribeMap.call(OnSubscribeMap.java:48)
    at rx.internal.operators.OnSubscribeMap.call(OnSubscribeMap.java:33)
    at rx.Observable.subscribe(Observable.java:10423)
    at rx.Observable.subscribe(Observable.java:10390)
    at rx.Observable.subscribe(Observable.java:10298)
    at org.dryft.azure.Agreements$.acceptTerms(Agreements.scala:102)
    at org.dryft.azure.Agreements$.$anonfun$main$2(Agreements.scala:128)
    at scala.concurrent.Future.$anonfun$flatMap$1(Future.scala:307)
    at scala.concurrent.impl.Promise.$anonfun$transformWith$1(Promise.scala:41)
    at scala.concurrent.impl.CallbackRunnable.run(Promise.scala:64)
    at java.util.concurrent.ForkJoinTask$RunnableExecuteAction.exec(ForkJoinTask.java:1402)
    at java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:289)
    at java.util.concurrent.ForkJoinPool$WorkQueue.runTask(ForkJoinPool.java:1056)
    at java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1692)
    at java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:157)

To Reproduce

  1. Get an agreement from a (publisher, offer, plan) triplet
  2. Modify the accepted boolean of the returned agreement
  3. Update the agreement

Code Snippet

Simplified async pseudo-code:

val terms = client.marketplaceAgreements.getAsync(publisher, offer, sku)
client.marketplaceAgreements.createAsync(publisher, offer, sku, terms.inner.withAccepted(true))

Additional context

Similar issue on node sdk: https://github.com/Azure/azure-sdk-for-node/issues/2423

For some reason, the date is not formatted properly and skips some milliseconds. Milliseconds that changes the signature of the query and makes it fail.

Returned agreement after the first GET query:

{
  "properties": {
    "retrieveDatetime": "2019-11-07T12:19:46.796698Z",
    "signature": "SOME_SIGNATURE",
    "accepted": false
  }
}

Updated agreement for the PUT query:

{
  "properties": {
    "retrieveDatetime": "2019-11-07T12:19:46.796Z",
    "signature": "SAME_SIGNATURE",
    "accepted": true
  }
}

The 698 missing part just before the Z of the retrieveDatetime is the issue.

Marketplace Ordering Mgmt Service Attention bug customer-reported

All 13 comments

Thanks for reporting this issue. Someone from the Management Plane will take a look and get back to you.

Hi @joshfree
Can we have an update on this one?
Thanks.

hi @xccc-msft could you pls help to have a look? thanks

@notdryft This is caused by the DateTimeSerializer. We will need some time to figure out whether this should be fixed from server side or SDK side.

cc: @jianghaolu

For track 1 in order to support Java 7 we only have millisecond support through joda time. Microseconds require Java 8 and above. See this post for details: https://stackoverflow.com/a/33487917

For now you may have to change the type of the field to a string manually. In track 2 we are targeting Java 8 and uses java.time with microseconds support.

Thanks for the feedback! We are routing this to the appropriate team for follow-up. cc @prbansa.

@jianghaolu Thanks for sharing this.
@notdryft I just checked the service swagger. It looks there were changes for date time format, and later the changes got reverted. I just add label of Service Attention. We need help from service team to confirm whether it should be only a manual fix on Java or a common fix on swagger. After that, we could apply the changes and plan for new release.

Any update on this? It's been 6 months and this API is basically broken.

This is one of the more cryptic message that I have got lately …… 😊 I am not sure what is need here and what is the ask , and not even sure at what area.

From: Pradeep Bansal Pradeep.Bansal@microsoft.com
Sent: Friday, June 5, 2020 10:33 AM
To: Azure/azure-sdk-for-java reply@reply.github.com; Azure/azure-sdk-for-java azure-sdk-for-java@noreply.github.com; Aviv Friedin avivfr@xbox.com; Aviv Friedin Direct Reports avishapdir@microsoft.com
Cc: Mention mention@noreply.github.com
Subject: Re: [Azure/azure-sdk-for-java] [BUG] Signature does not match when accepting a marketplace ordering agreement (#6206)

Adding ILDC folks for further updates here.

Get Outlook for iOShttps://aka.ms/o0ukef


From: Stephane Landelle <[email protected]notifications@github.com>
Sent: Friday, June 5, 2020 12:14:57 AM
To: Azure/azure-sdk-for-java <[email protected]azure-sdk-for-java@noreply.github.com>
Cc: Pradeep Bansal [email protected]Pradeep.Bansal@microsoft.com>; Mention <[email protected]mention@noreply.github.com>
Subject: Re: [Azure/azure-sdk-for-java] [BUG] Signature does not match when accepting a marketplace ordering agreement (#6206)

Any update on this?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FAzure%2Fazure-sdk-for-java%2Fissues%2F6206%23issuecomment-639302958&data=04%7C01%7Cavivfr%40xbox.com%7C0b1322f8a2044a0e36ff08d80922bd74%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637269392120642845%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C-1&sdata=nXZl0xNxRPWV4QgbH37E6KY9PCML6HLCRyapTKKaYOw%3D&reserved=0, or unsubscribehttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAHNECBXUASKQHPUKAIYOP2DRVCLPDANCNFSM4JKGJ7PQ&data=04%7C01%7Cavivfr%40xbox.com%7C0b1322f8a2044a0e36ff08d80922bd74%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637269392120652836%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C-1&sdata=Iis7veVWyVXqFRr9cCCJhZr5XTamVJO59PgjQHNyX10%3D&reserved=0.

@prbansa It looks a common issue across the SDKs like Node, Python and now Java.
The ask is:
Can we change the date-time format in swagger for fixing the unsupported precision in SDK clients?

@prbansa: any updates?

@prbansa It looks a common issue across the SDKs like Node, Python and now Java.
The ask is:
Can we change the date-time format in swagger for fixing the unsupported precision in SDK clients?

hi @prbansa do you have enough information to help on the issue? PIng us if you need more info. cc @weidongxu-microsoft

Was this page helpful?
0 / 5 - 0 ratings