Skip to content

fix: broken JSON round-tripping for custom claims#3819

Merged
alnr merged 2 commits intomasterfrom
alnr/fix-session-data
Aug 14, 2024
Merged

fix: broken JSON round-tripping for custom claims#3819
alnr merged 2 commits intomasterfrom
alnr/fix-session-data

Conversation

@alnr
Copy link
Copy Markdown
Contributor

@alnr alnr commented Aug 13, 2024

Adding custom claims with numerical types (think JavaScript Number) previously did not
round-trip through Hydra correctly. For example, passing UNIX timestamps in custom claims
would end up as floating points in exponential notation in the final token. That, in turn,
confused or broke downstream consumers of the token, including Kratos.

Ref go-jose/go-jose#144

alnr added 2 commits August 12, 2024 17:18
Adding custom claims with numerical types (think JavaScript Number) previously did not
round-trip through Hydra correctly. For example, passing UNIX timestamps in custom claims
would end up as floating points in exponential notation in the final token. That, in turn,
confused or broke downstream consumers of the token, including Kratos.

Ref go-jose/go-jose#144
@alnr alnr self-assigned this Aug 13, 2024
@alnr alnr requested review from aeneasr and hperl as code owners August 13, 2024 15:08
@aeneasr
Copy link
Copy Markdown
Member

aeneasr commented Aug 14, 2024

There was this PR: #3722

Is that the same issue, and if yes, #3722 seems to use the number decoding in more places.

@aeneasr
Copy link
Copy Markdown
Member

aeneasr commented Aug 14, 2024

Also, are there any implications for backwards compatibility with prior consent sessions?

@alnr
Copy link
Copy Markdown
Contributor Author

alnr commented Aug 14, 2024

Yes I did see #3722. As the author discovered, using json.Number does not fix this issue. The underlying problem is described here: go-jose/go-jose#144

I don't think this will cause any regressions. This change mostly or exclusively impacts how numbers are serialized into the final token, it doesn't really change any underlying data. While we're handling the custom claims in hydra, we serialize+deserialize them to/from JSON a couple of times. Each time, any "type" information about whether the number is a float or integer is lost since this distinction doesn't exist in JSON.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants