SignedRequestStrategy timestamp may use scientific notation on PHP 8.4, causing signing failures

[paulgibbs]

Hi Yoti team,

We encountered a signing failure when using the PHP SDK on WP Engine FPM running PHP 8.4.22.

The issue appears to come from the timestamp generated in:

Yoti\Http\AuthStrategy\SignedRequestStrategy::createQueryParams()

The current upstream code casts the rounded millisecond timestamp to a string:

'timestamp' => (string)(round(microtime(true) * 1000)),

In our environment, this can produce a timestamp in scientific notation, for example:

timestamp=1.78231576830E%2B12

That timestamp is included in the signed request URL, and Yoti rejects the request with:

401 - MESSAGE_SIGNING - The message was not signed correctly

We patched the SDK locally by formatting the timestamp as a plain integer string:

'timestamp' => sprintf('%.0F', round(microtime(true) * 1000)),

This produces the expected millisecond timestamp format, for example:

1782315979361

After applying that change, the signed request timestamp is emitted as a plain integer and the signing failure is resolved.

Would you consider updating SignedRequestStrategy::createQueryParams() to force a non-scientific integer timestamp string?

--

The above was written up from an issue ticket by AI, but I reviewed and debugged and tested the issue (as a Human!). If any more information or testing can be done on the environment in question, please let me know. Happy to help.

[sophymarine]

That (string)(round(microtime(true) * 1000)) line is where it goes sideways on PHP 8.4. The moment the value becomes a float, PHP may stringify it in scientific notation. Whether that happens depends on the FPM pool’s serialize_precision and precision. If that string ends up inside the canonical request, the signature no longer matches.

Your sprintf('%.0F', …) change is a solid guard. It forces a plain decimal string.

Another route is to skip floats altogether. intdiv(hrtime(true), 1_000_000) returns a millisecond timestamp as an integer, so the later string cast stays stable. That tends to behave the same across different php.ini settings, which avoids this class of signature mismatch.