HandleURL problem with Paddle Webhook - Web 2.0 only

Targets Web
1

Please does anyone have any ideas why Paddle.com Webooks appear not to fire the HandleURL event in Web 2.0?

I have an existing Web 1.0 project working great on AWS receiving POST from Paddle Webhooks via HandleSpecialURL.

I upgraded to the new Web2.0 with HandleURL but now the Paddle Webhook times out and the following code at the start of the HandleURL event is not even triggered:

System.Log(System.LogLevelInformation, “path” + Request.Path)
System.Log(System.LogLevelInformation, “body” + Request.Body)
System.Log(System.LogLevelInformation, “queryString” + Request.QueryString)

If I use Paw and send exactly the same POST data as Paddle says it sending, the new Web2.0 works great, as do all the other URL handling features in my application that have nothing to do with Paddle.

This is a standalone web app that I’ve run by double clicking, and I also tried installing as a Windows Service but I get the same results.

I know the Paddle data gets to the AWS windows server because the Web1.0 works great.
I am fairly confident that the address, port, URL structure, and code inside the HandleURL Event is correct because I can POST the exact same thing from Paw on my local machine to the AWS address and it works using Web 2.0 framework.
I’ve tried a new AWS windows instance disabling all firewalls and security and I get exactly the same results.

Hopefully it is something that I’m simply overlooking, but I’m at a bit of a loss so any help would be appreciated.

2

Make sure your Request.* output is changed to Response.*
For example to write the response:

 Response.Status = 200
 Response.write "mydata"
 Return True
3

Yes. I upgraded the code to comply with the HandleURL requirements:

Case "api/paddle"
  System.Log(System.LogLevelInformation, Request.Body)
  ProcessPaddleText(Request.Body)
  Response.Status = 200
  Response.Write("Received Webhook")
  Return True
1 Like
4

Have you tried sending the Paddle hook data to webhook.site? That should show you the entire request to ensure you’re recreating it completely in Paw.

HandleURL should be raised for every request, even ones destined for a web session. It’s quite curious that requests from Paddle are timing out.

I wish I had more reassurance for you, but my DRM systems are built in Web 1.0.

5

Thanks Tim - good tip!

In Paw, if I include the header that Paddle sends:

Expect: 100-continue

This triggers the timeout problem.

Screenshot 2021-03-27 at 14.45.39

So a bit closer to solving it…

6

This is where I’d loop in @Greg_O_Lone for some insight.

Update: Out of curiosity I tested the header and can confirm this behavior.

7

If you get the header, you need to check the other headers and make sure your app can handle such a request. To be honest, I have no idea why you’d use this header for a request that’s that small as the overhead of sending the request twice is about 50% more data. Usually this is for clients that want to send mega or gigabytes of data and want to make sure the client can handle it.

Anyway, if you have this header, set the response status code to 100 for Yes or 417 for No and return True. The real request should then be sent by the client.

8

HandleURL is never raised.

9

Oh… hm. Well if you file a bug report I’ll look at it Monday.

10

Can do, <https://xojo.com/issue/64192>

2 Likes
11

This is probably because paddle.com doesn’t expect a server to process an invalid request to the webhook anyway. Making the webhook more secure. So they expect you to process the headers, see if it’s a valid request the return HTTP 1/1 100 Continue and then process the body and respond again with 200 OK or whatever response is expected. If the headers are invalid (security hash or signature is not accepted) the server should respond with an error for example 403…

Paddle makes this overly complex. It’s far easier and more secure to just provide an id for the payment is a POST parameter to the server / webhook and then have the server call the paddle service to verify (using a secret or api key or such). Currently not possible with paddle.

I hope xojo can fix this to ability to handle these kind of requests.