Closed kanongil closed 2 years ago
On PR #22 -
I encoded both the header and the payload, because of the option to add custom fields to the header. Upon sleeping on it, I think that encoding the entire header is a bad idea as it may make the entire token invalid. So my options are
Doing 1 is easier, but I prefer 2. I will look at the lift on this tonight (Chicago time) and adjust accordingly.
After even further thought I realized that they payload is subject to the same problem. If Reserved Claims (aud
, iss
, sub
, iat
, etc... are encoded, the key is rendered useless.
Perhaps this is why Eran never fully implemented this feature. Going to play around with some things. However I have removed this from my PR for documentation and IMHO getting that out is the most important thing as the appearance of this module has caused confusion, discussion, and debate on the web since being open sourced.
Sorry if I'm being too verbose, but closed pr #22 as I was decreasingly liking my solution. Will think on other things or allow someone else to take a stab.
Have finally circled back here. After looking at what is out there it appears that the often used JWS
module supports encoding of the payload, however there are not any modules I found that supported non utf8
encoding when validating the token. Now we will!
Resolved by #39 and #47.
It does not support a second
encoding
argument.https://github.com/hapijs/jwt/blob/634ce2f79b0bf684d35519ff63fa9553a6896517/lib/token.js#L44
https://github.com/hapijs/jwt/blob/ca6bad9165b6f7cd781aca5f8ab9f5927b8c9e47/lib/utils.js#L9