Closed spacewander closed 3 years ago
I'm confused what the issue is here? Can you give a little more context?
You can run this repo's test suite both under OpenResty 1.17 and under OpenResty 1.19, and then you will find the output is different.
I'm still confused because the internal lua data structure you're referring to is a table. I don't believe there are assurances to key order for these tables.
Is there a specific test that is breaking?
I believe to maintain compatibility while verifying we need to make sure we use raw header received to recalculate signature (but verifying lua table equivalent of that header does not have any other fields) . I will be using OpenResty 1.19 soon for my internal app. Will definitely lookout for any incompatibilities between (1.17.x and 1.19.x ) and submit PR to maintain compatibility if any discrepancies are found.
Don't be panic! I should clarify that even the tokens are different, they both can be verified by different OpenResty versions. Because during verification, the token will be decoded to get the payload, and the signature part of a token is calculated base on the first two parts of the passing token. So even the tokens are different, the verified results are the same.
The original title is misleading. What I want to mean is the output of jwt.sign
, which is token but not signature.
just to close loop on this - I was able to verify token issued between 1.17.x and 1.19.3 versions are compatible in my real world test!
Because the results of
cjson.encode
are different.Under OpenResty 1.17:
Under OpenResty 1.19: