Verify Webhook with Umlauts/Special Characters

[MaxMelcher]

Describe the bug

Dear team,

we use the SDK to verify webhooks and it works for 99% of the cases.
For the failing ones we noticed that the customer have special characters e.g. in the customer name (e.g Ü Ä Ö for German customers or Å/å) and the validation fails.

We added a unit test for these payloads and its reproducible - but we cant share it because it contains customer data.

How can we validate in these cases?

Thanks,
Max

Steps to reproduce

Added the following test with a vailing JSON payload.
Also tested it with a valid one to ensure that the code works.

Expected behavior

Webhook validation successful

Code snippets

/** @test */
        public function it_verifies_a_signature2(): void
        {
            $json = '<PAYLOAD WITH SPECIAL CHARACTERS>';

            $request = Psr17FactoryDiscovery::findRequestFactory()
                ->createRequest('POST', '/paddle/notifications')
                ->withHeader(
                    PaddleSignature::HEADER,
                    '<header>',
                )
                ->withBody(
                    Psr17FactoryDiscovery::findStreamFactory()->createStream($json),
                );
    
            $secrets = [
                // The correct key
                new Secret('<KEY>'),
            ];
    
            self::assertTrue((new Verifier(null))->verify($request, ...$secrets));
        }

### PHP version

PHP 8.2.7

### SDK version

latest

### API version

version 1

### Additional context

I can share the json payload / key via email if needed: firstname@lastname dot it

[mikeymike]

Hi @MaxMelcher thank you for taking the time to report this, we can definitely improve our test coverage here to ensure this package is handling this correctly.

I've taken some time to add a couple of test cases that I hope covers your use case here which I've added in PR #49. Would you be open to take a look and letting us know if this does indeed cover your usage?

With the tests passing in the PR it does prompt a few possible questions that maybe you could elaborate on for your usage.

1. How is the request object you provide to the verifier constructed?
2. Are you using any framework that is handling the request object first?
3. Is there any possible middleware running potentially mutating the request in anyway?

I'll also note that while testing this I noticed a strict difference between escaped characters and their printed counterparts, e.g. Ü would not verify the same as \u00dc which is how the raw request is received in my testing.

I'd really like to figure out the point of failure here so we can make this process as streamlined and robust as possible

[MaxMelcher]

Hi @mikeymike,

thanks for this - we might not have access to the raw request.

We use Azure LogicApp as receiver of the notification. This allows us to easily replay notifications and decouple the from our application.
Paddle --> LogicApp --> our Api that verifies the webhook payload.

The payload is decoded when the logicapp receives the paddle request - we have done this also in the with the previous paddle API that needed the public key to verify. With the old API we did not experience this issue with hundreds of transactions.

Not sure what we can do on our side. Any recommendations?

Thanks,
Max