Affects of php.ini setting serialize_precision

[3cooper]

We ran into an issue when updating our site to PHP 8.1 and its dependencies. The generated access tokens had an iat set in the future. After a lot of digging, it seemed that the cause for us was that our serialize_precision setting in php.ini was set to 8. The date inputs going into the token were correct, but when converted to a float and then JSON encoded, the date could be modified. I'm pointing this out to both check my understanding and help out anyone that could run into a similar issue.

[Slamdunk]

This seems an interesting issue: do you mind creating a test that reproduces it in a PR?

[lcobucci]

It seems like, since PHP 7.1.0 we need the precision to be at least the length of $date->format('Uu') (it could be -1 too).
More info: https://3v4l.org/UGuFv and https://3v4l.org/dQHFK

[lcobucci]

I love floating points: https://3v4l.org/0jE0W 😭

Testing "2286-11-20 17:46:39.999994" with given precision (-1)
string(17) "9999999999.999994"
string(17) "9999999999.999994"
bool(true)

Testing "2286-11-20 17:46:39.999995" with given precision (-1)
string(17) "9999999999.999995"
string(17) "9999999999.999994"
bool(false)
Testing with adjusted precision (16)
string(17) "9999999999.999995"
string(17) "9999999999.999994"
bool(false)

Well, I guess we have ~250 years to figure out a better solution 😅

[lcobucci]

So, the main question here is: What's the way forward?

Doubles are constrained and will lead us to limitations (regardless of the language).
We can't run away from them, as well, as the JWT spec expects a JSON number.

Validating serialize_precision can be a good enough approach for the existing implementation - to at least alert people and suggest the usage of UnixTimestampDates instead of the MicrosecondBasedDateConversion.

A random thought

The UnixTimestampDates component is limited to PHP_INT_MAX, given the JSON number type isn't bound to int|float we should review this and avoid having exceptions on $date->getTimestamp() calls for dates that don't fit in integers (after 2038-01-19 03:14:07) - which will lead us to similar limitations with serialize_precision

Random insights

• Encoding the current time (1693949426) as a float requires a minimum serialize_precision of 10 - it's surely not the correct data type to use for that value, as it's <= PHP_INT_MAX, but it gives some ideas around the min value for serialize_precision
• A serialize_precision of 16 allows us to reliably represent far-away dates, if we "play" with time fractions:
  • 2286-11-20 17:46:39.999994 (9999999999.999994)
  • (...)
  • 33658-09-27 01:46:39.999400 (999999999999.9994)
  • (...)
  • 31690708-07-05 01:46:39.400000: (999999999999999.4)
• A serialize_precision of 17 allows us to reliably represent the maximum value ever: 316889355-01-25 17:46:40.000000 (10000000000000000)

[lcobucci]

@3cooper thanks a lot for creating this discussion, as you can see it really triggered me 😂

[Slamdunk]

The UnixTimestampDates component is limited to PHP_INT_MAX, given the JSON number type isn't bound to int|float we should review this and avoid having exceptions on $date->getTimestamp() calls for dates that don't fit in integers (after 2038-01-19 03:14:07)

2038-01-19 03:14:07 is the limit for 32bit systems only (PHP_INT_MAX === 2147483647), while 64bit systems have no issue going further (PHP_INT_MAX === 9223372036854775807, which means +292277026596-12-04 15:30:07.000000).