You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It took me awhile to finally track down the source of a subtle bug that appeared when I started to use this library to generate and validate dpop proof tokens (a form of jwt).
The token header and claims look something like this
When I attempt to encode this token with jwt.encode and then decode it, the header has been altered (in place too, an original reference to the header dict now has the 'typ' key changed to 'JWT').
I can't tell you how excited I was to learn this library existed not long ago, Python has been sorely lacking a clean, no bs, pythonic jose implementation. But this hardcoded typ makes it impossible to use for one of my use cases (one of which is dpop validation) because I'm unable to generate test case material at runtime.
I understand not wanting to support a draft spec until its at least more mature, but I think at this point, dpop is here to stay and my ask would only be adding some flexibility in order to make such a use case possible. So my question is, how best can I scratch my own itch here? What kind of change would you accept in PR form to open up the typ value a bit? Initially, I was thinking 'typ' could be something that can be overrided in JWSRegistry kinda like registering custom header claims. What do you think?
Thanks for the great library and your time btw!
The text was updated successfully, but these errors were encountered:
It took me awhile to finally track down the source of a subtle bug that appeared when I started to use this library to generate and validate dpop proof tokens (a form of jwt).
The token header and claims look something like this
When I attempt to encode this token with
jwt.encode
and then decode it, the header has been altered (in place too, an original reference to the header dict now has the 'typ' key changed to 'JWT').It would seem this line at the top of encode is the culprit https://github.com/authlib/joserfc/blob/main/src/joserfc/jwt.py#L61
I can't tell you how excited I was to learn this library existed not long ago, Python has been sorely lacking a clean, no bs, pythonic jose implementation. But this hardcoded typ makes it impossible to use for one of my use cases (one of which is dpop validation) because I'm unable to generate test case material at runtime.
I understand not wanting to support a draft spec until its at least more mature, but I think at this point, dpop is here to stay and my ask would only be adding some flexibility in order to make such a use case possible. So my question is, how best can I scratch my own itch here? What kind of change would you accept in PR form to open up the
typ
value a bit? Initially, I was thinking 'typ' could be something that can be overrided inJWSRegistry
kinda like registering custom header claims. What do you think?Thanks for the great library and your time btw!
The text was updated successfully, but these errors were encountered: