Closed elliotcourant closed 7 months ago
A workaround for this is to add the string
tag to fields with large numbers like:
ID uint64 `json:"id,string"`
But I think that the value changing at all as part of the transformation process still qualifies this as a bug? Either limits should be imposed on what type of data can be provided to ensure that data does not change in the process of creating/parsing a token, or the data should simply not be transformed?
Thanks for the report! I haven't had a chance to sit down and step through this in code myself, but I would agree that this looks like a bug.
The intermediary stored serialisations are a bit of a "hack" to offload marrying up the JSON with the requested type to the JSON unmarshaller (since doing it upfront means I'll get just plain strings,ints,etc... back instead of the wanted type).
My immediate thought here is that I could still immediately serialise the value within the token type when setting, but store it as a json.RawMessage
instead so that it does not require the deserialise-serialise dance when serialising the whole token. The same would apply when decoding so that the decoding step is just delayed until the type is known.
Thank you very much, hopefully its not a huge change. I had messed around with it a bit last night but didn't get very far. Thank you for the library though!
https://github.com/aidantwoods/go-paseto/pull/48 should resolve this, I included your test to guard against regressing back to the current behaviour (thanks for that 🙂)
Thank you very much!
Fix available in v1.5.1. Thanks for the report!
I'm having an issue where large values are not being encoded properly. For example if I try to encode a value with a large uint64:
The resulting token will look like this:
This is because the values are encoded into JSON once when you call
Set
but then when you callV4Sign
they are decoded in Claims() and then re-encoded in ClaimsJSONSet
https://github.com/aidantwoods/go-paseto/blob/819992509ce748c6367d3dd4a4f2d11bd74397b2/token.go#L51-L60
Claims
https://github.com/aidantwoods/go-paseto/blob/819992509ce748c6367d3dd4a4f2d11bd74397b2/token.go#L116-L131
ClaimsJSON
https://github.com/aidantwoods/go-paseto/blob/819992509ce748c6367d3dd4a4f2d11bd74397b2/token.go#L134-L141
This encode -> decode -> re-encode is causing the type of the data to be completely lost, and go has to assume the type; during the decode it assumes that the value is a float64 so you end up getting floating point errors and the value of the field changes during these transitions.