Opayo provider callback fails about vendr-payment-provider-opayo

[mattbrailsford]

I personally think it might be the fact we have a /umbraco/vendr/ based URL for the payment controller. This was by design as in v8 (not sure if it's still true in v9) this was the easiest way to have a URL that didn't need excluding from Umbraco via web.config. But my thinking is, because it starts /umbraco maybe some other Umbraco based middleware is running that reads the body and so it's getting read before it gets to us and thus can't be rewound.

My work around is to inject our own middleware that runs first and sees if it's a request for our API controller and if it is, enabled buffering on the request such that we CAN rewind the request.

I do wonder if changing urls to not have /umbraco in them might fix this, but I don't currently want to introduce a difference between v8 and v9 so we'll stick with this custom middleware for now.

[mattbrailsford]

I believe this should be resolved in the current unstable feed. The problem was the new PaymentProviderContext wasn't being updated with the request object when it was converted into a stronly typed model. This has now been resolved.

There should be a 2.0.1 build on the unstable feed if you want to test it, otherwise the update will be pushed out some time this week.

[callumbwhyte]

@mattbrailsford We have upgraded to Vendr v2.0.2 and it definitely fixed something but still not quite right...

The request is there now, so no more nulls, but it's empty... No values whatsoever...

I've done some more digging and it seems the RequestMessage in the VendrPaymentController is the culprit. Creating an HttpRequestMessageFeature from an HTTP context results in an empty request, but by reading the request directly I was able to get all of the values. See below:

// this is empty
var ctxFormData = await ctx.Request.Content.ReadAsFormDataAsync();

// this has values
var httpFormData = await _httpContextAccessor.HttpContext.Request.ReadFormAsync();

// this is empty
var reqMsg = await new HttpRequestMessageFeature(_httpContextAccessor.HttpContext).HttpRequestMessage.Content.ReadAsFormDataAsync();

[mattbrailsford]

Yea, unfortunately IHttpContextAccessor isn't .NET Standard.

Usually if the ReadAsFormDataAsync() result is empty, this generally suggests the request body has already been processed somewhere as HttpRequestMessages can only have their body processed once. Looking at the code for the provider though, it does look as though it's only being called once in the codebase so I can't think why it would have already been processed 🤔

Have you modified the code in any way that would cause the ctx.Request.Content to be processed twice?

[callumbwhyte]

Worked through this with @mattbrailsford on Friday and confirm that v2.0.3 on the unstable feed has fixes for this!

Context: the Content stream used to get content from the HTTP request is being read by something, and can't be reset to the start of the stream when it gets re-read. This doesn't seem to have broken any other providers, so there's possibly some code in the Opayo provider actively reading the request more than once.

[mattbrailsford]

Fix is in Vendr 2.0.3 release.