Honor the callbackAddress in consumer control plane tests#29
Conversation
31a5f05 to
45cd7b5
Compare
c7391bd to
1709bb8
Compare
ndr-brt
left a comment
There was a problem hiding this comment.
to speed up the review process, when you are ready for a new review, please re-request a review, so I'll get a notification.
| ); | ||
| var response = send(protocolUrl + "/transfers/request", requestBody, "consumerId"); | ||
| return response.get("providerPid").toString(); | ||
| var response = send(initialDspUrl + "/transfers/request", requestBody, "providerId"); |
There was a problem hiding this comment.
why the senderId became providerId? this is breaking the control-plane provider tests
There was a problem hiding this comment.
sorry this was an unrelated changes that I've reverted now.
but IMHO the authorization gets really strange without it, e.g. in tests like CP_P:01-01
the TCK will first send a POST /api/dsp/2025-1/transfers/request with Authorization: {"clientId":"consumerId"} and then follow up with POST /api/dsp/2025-1/transfers/d11d5caf-e2af-45b8-a7df-11368705cf45/completion with Authorization: {"clientId":"providerId"} which really trips up validation in my control plane.
Authorization should be out of scope of the tck so I'll try to find a workaround for this.
There was a problem hiding this comment.
this is, indeed, an EDC thing. I'll create an issue for this.
Example implementation for how the dps-tck could be updated to respect the
callbackAddressas discussed in #28