Update return type for jwt.encode

[moomoolive]

It seems to me that the return type for the encode method is actually 'bytes' type and not 'str'. While this doesn't make a huge difference working with python code, it gave me some issues yesterday when sending JWT tokens between a Python (flask) REST API and Javascript (Vue) frontend.

[auvipy]

can you share what errors you are facing?

[moomoolive]

It was honestly pretty simple, since the 'jwt.encode' method outputs a bytes object and not a string, I ended up sending something that looked like this to my front end application:

b'the_jwt_token'

instead of just the token itself.

The problem arose when I tried to use the token for authorization (decode it), where it would throw an 'invalid header padding warning' because I was sending the bytes object of the token, instead of the string of the token itself.

Hope that makes sense.

[tlinhart]

@moomoolive @auvipy I think this PR should be reverted as it seems that #513 actually made encode return a string. PyJWT.encode() uses its base class' encode method which returns string, see

pyjwt/jwt/api_jws.py

Line 130 in 96ec863

return encoded_string.decode("utf-8")

.

[moomoolive]

@tlinhart although the line of code you referenced above should have solved the problem it doesn't seem to, at least when I try it in my terminal. (BTW I'm using the latest distribution of library 1.7.1)

It only becomes a string when I decode the token with ASCII.

Maybe decoding needs to be in ASCII??

[tlinhart]

Well, in 1.7.1 it returns bytes, but not in master. The current (master) version returns str and thus this PR (which was merged into master 8 days ago) should be reverted.

[rayluo]

@tlinhart was right on this:

Well, in 1.7.1 it returns bytes, but not in master. The current (master) version returns str and thus this PR (which was merged into master 8 days ago) should be reverted.

And, to document my investigation findings here: even though this PR was mentioned in the v2.0.0 release notes and changelogs, but that line was indeed reverted subsequently. In other words, encode(...) returns a string, not bytes.