Usage of `json_encode()` to convert time fractions to microseconds cause precision issues

[sn-sharma]

message: "Value is not in the allowed date format: 1616481863.528781890869140625"

[Slamdunk]

May you share with us:

1. the version of lcobucci/jwt you are using
2. whether the parsed token was created by lcobucci/jwt itself or by an external tool
3. if the token was created by lcobucci/jwt, a snipped that reproduce the errored token

?

[lcobucci]

A stack trace and a sample token would also be quite helpful 👍

[RyanTheAllmighty]

Yup I'm also getting Value is not in the allowed date format: 1616497608.0510409.

Sample token:

eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiJ9.eyJhdWQiOiIyNzZhM2JjOC1jY2JkLTRmMDMtYTlkMi1mZDcxZGYxOGZkZGYiLCJqdGkiOiJiYTFjZGFlZDkzYzEwZDc2ZTY2Y2Y5OGEwNTU0NWYxZDIzMzIyY2E4YzZlNDY0OGY4ZTUzOTAyZWVkYmZmYTY4ZDQ3MWJhZTNkZjIxYmNkMSIsImlhdCI6MTYxNjQ5NzUwOC43OTU2MTcsIm5iZiI6MTYxNjQ5NzUwOC43OTU2MiwiZXhwIjoxNjE2NTAxMTA4LjY4MTYzLCJzdWIiOiIzIiwic2NvcGVzIjpbImlkIl19.CeqmJ8VliEGLQVsqhmSTWHJcwtlYS0nMKkbLqMuLybqM2Bn_CxRzJEC4y3W3ez5OXf7W6aNSbMM4MEMFCSisT-sOZ1k_EudQSjA7lpWcWxw3J8j09H9EPanJnkPYYwuDnPQAiKkYpuZxD05aWAi-NnzBBh3Lq1PMScANQZE0uhWf_cpgnoHAS_b_wvjyBVn0PFxtIzi-qN8JP95Luvy3UfzrnsnWR7WeVdwe_ecx511E4asLTk_-fooRwklLW8qpuEvG1JnEpCEalnaRXrR2xUa9hIB6ogJnk4WWgWDbIyB0QubNBROfVaPXTbHppYENGROOJs8RCLi61Z9U_QkwO4nu54ZU-n9KWupUGgJMNV9ZJ9QOWDLT-7KlOumw8VzuZWIrZmYNjUmAoKkh7O_z6xrfXE1X1uUIgWbyxR9GgQgHTRmQZZtH93dhF-guYij6gZuRbJ723iQr-ddPV02h6bT1Z90dEpHRgPinx2VMZ_oNGpPTUlIX2ErqMdWQ5Cn5Wr6qYqYLsiaxxyQy2btU7FK3Fss3ifo5v1U5-Ay0uJhe5ygu49ymDraYNntdn05BpdTit-UiC2kPrtdX11eYiYZTrKkCymg5Qj5up1FZRTMxwmrr10dKOVAJ3cVRq5AZLRGTZ_ETTt8v1dfG5XKEOsisUibOEVn8ZU-kpgyc-O4

Downgrading from version 4.1.3 to 4.1.2 fixed the issue.

I use laravel/passport to generate the tokens which uses oauth2-server as the server which generates the tokens using lcobucci/jwt.

Not sure if this issue sits on the Laravel Passport implementation side (with oauth2-server package) or with this package, but again locking the version to 4.1.2 fixed it for me, and figured I'd pop a message on the issue for anyone else coming across this.

After reverting the version, this is the token I have:

eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiJ9.eyJhdWQiOiIyNzZhM2JjOC1jY2JkLTRmMDMtYTlkMi1mZDcxZGYxOGZkZGYiLCJqdGkiOiI0ZGFkMzFmZjE0YzZjNDhiZjFmNzgzNDA3NDdhMjE1MjZjM2UwNDU1OTZlNzIxZjAzZmIzNGM2MDg1ZWI0NzI4MjM1MTRlOGFmNmIyNDNkNCIsImlhdCI6IjE2MTY1MDM2MTkuOTcyNDMxIiwibmJmIjoiMTYxNjUwMzYxOS45NzI0MzciLCJleHAiOiIxNjE2NTA3MjE5Ljg1NDc1NCIsInN1YiI6IjEiLCJzY29wZXMiOlsiaWQiXX0.ZhpX_x6ahBCEP88NN45hdhK1-WbP7ga5YOYd3lnWcVch4o1Nn9NpQ6RQnPM8NmSKTy_Bv0EFWsSLBuJZunDSqm82LMgBFyWownUtG_ZaXRJXd2lORDxCQhbYs1uSWcufD64OJXmpj1GnjqZ7HexJxe7xHUUMrhaKELuulIBUpCcPPxWWksw-zN4Znm7gT71EY3Db_LrieOy0UdYDiYqPK4UoLavxk9z7ObXkePEXtaCPk0S_xsb4uWxpgWgnkt3pdf5E0L88o_maRYeLrzP42mi0Keq3c9K6-4tXopQIkJwpFc03DFFDZQCrCRvwK3Ot0cc_pFgQt78LpyRBukcXs01q_ACiG2WRNxOBP9hx582lciOAyp_FTPyXRaW14IE75otPrBYzFm0iQt_w3JSGkMsDhocM4h_IRPja4zUwlFLFTzLoT9mLaJVzrc9eo103YPGfnzSJyqgFoMJClVlyf7zNk0DWRCiucrFspE07rdTvn3Z6rPBGuMQnYe0WRMR8KX3pl1hokFlW7p8T2EEbo9o08QGnTnjnOjlWs6jIrHFuRszRXDY1plsL8XEjbfUlvHvM9JImo1cr3kRv1nqZgvYJZtNR6O5jwQjdxsT9IL7jwwG23jWMu7xuXCrVYwbnR_ZfOdE7oKg_B31cjBfP4YiGGxde-JMCnDAlO56JfkM

The only difference is as per the release notes, the timestamps are floats instead of strings now.

[Slamdunk]

Yup I'm also getting Value is not in the allowed date format: 1616497608.0510409.

Sample token:

eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiJ9.eyJhdWQiOiIyNzZhM2JjOC1jY2JkLTRmMDMtYTlkMi1mZDcxZGYxOGZkZGYiLCJqdGkiOiJiYTFjZGFlZDkzYzEwZDc2ZTY2Y2Y5OGEwNTU0NWYxZDIzMzIyY2E4YzZlNDY0OGY4ZTUzOTAyZWVkYmZmYTY4ZDQ3MWJhZTNkZjIxYmNkMSIsImlhdCI6MTYxNjQ5NzUwOC43OTU2MTcsIm5iZiI6MTYxNjQ5NzUwOC43OTU2MiwiZXhwIjoxNjE2NTAxMTA4LjY4MTYzLCJzdWIiOiIzIiwic2NvcGVzIjpbImlkIl19.CeqmJ8VliEGLQVsqhmSTWHJcwtlYS0nMKkbLqMuLybqM2Bn_CxRzJEC4y3W3ez5OXf7W6aNSbMM4MEMFCSisT-sOZ1k_EudQSjA7lpWcWxw3J8j09H9EPanJnkPYYwuDnPQAiKkYpuZxD05aWAi-NnzBBh3Lq1PMScANQZE0uhWf_cpgnoHAS_b_wvjyBVn0PFxtIzi-qN8JP95Luvy3UfzrnsnWR7WeVdwe_ecx511E4asLTk_-fooRwklLW8qpuEvG1JnEpCEalnaRXrR2xUa9hIB6ogJnk4WWgWDbIyB0QubNBROfVaPXTbHppYENGROOJs8RCLi61Z9U_QkwO4nu54ZU-n9KWupUGgJMNV9ZJ9QOWDLT-7KlOumw8VzuZWIrZmYNjUmAoKkh7O_z6xrfXE1X1uUIgWbyxR9GgQgHTRmQZZtH93dhF-guYij6gZuRbJ723iQr-ddPV02h6bT1Z90dEpHRgPinx2VMZ_oNGpPTUlIX2ErqMdWQ5Cn5Wr6qYqYLsiaxxyQy2btU7FK3Fss3ifo5v1U5-Ay0uJhe5ygu49ymDraYNntdn05BpdTit-UiC2kPrtdX11eYiYZTrKkCymg5Qj5up1FZRTMxwmrr10dKOVAJ3cVRq5AZLRGTZ_ETTt8v1dfG5XKEOsisUibOEVn8ZU-kpgyc-O4

I'm sorry it seems to me the error you provided doesn't come from the token from the example.
The error has 1616497608.0510409 value but the example has 1616497508.795617, 1616497508.79562 and 1616501108.68163.

It is crucial for us to have the exact token that generates the issue: can you provide one of that kind please @RyanTheAllmighty ?

[sn-sharma]

When you are trying to send the $date value in convertDate() function in Parser.php file. It is checking for string but the value is 1616497508.79562, which is float. Then you are trying to convert with json_encode function which return the value in string like "1616497508.79562548484415745842262445584". Now the createFormFormat not able to convert it into date and through the mentioned error.

[Slamdunk]

The example you are providing doesn't match my tries: https://3v4l.org/ukgjM

Can you give us the original JWT token?

[lcobucci]

Maybe this is the cause/solution: https://3v4l.org/imDlQ

The re-encoded value (using JSON) has a different precision (goes beyond microsecond precision by 1 decimal place).
Using number_format() should mitigate that and we will have to accept that we might have a 1µs difference (negligible IMHO).

[sn-sharma]

I think you got that.
This is the cause https://3v4l.org/3Hlth

You are trying to cast the value as string.

[lcobucci]

An alternative would be keeping the json_encode() but ensuring we don't have more than 6 decimal places (substr + strpos). I think number_format() should work just fine.

Can someone send a PR against v4.0.x? We should have the necessary tests in place to guard against issues.

[Slamdunk]

My question is: how did more than 6 decimal places end up into the token in the first place?

[lcobucci]

My question is: how did more than 6 decimal places end up into the token in the first place?

I'm asking myself the same question... but we can only tell that based on sample tokens.

[Slamdunk]

Hence my question to @RyanTheAllmighty who seems issuing the token from lcobucci/jwt itself

[lcobucci]

https://3v4l.org/Xu3QH can be used to quickly detect the occurrence on a sample token btw.

[Slamdunk]

I'd suggest a bare base64_decode over the middle part of the token, without involving any json_* function: I don't trust them right now to provide me the correct raw informations ^^

[lcobucci]

The problem is that var_dump() and (string) round the floats never mind, I see what you meant. https://3v4l.org/plOsL