-
Notifications
You must be signed in to change notification settings - Fork 271
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add unknown variant to KeyAlgorithm #400
base: master
Are you sure you want to change the base?
Conversation
Co-authored-by: Vincent Prouillet <balthek@gmail.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks!
Looks like maybe proptest doesn't work on wasm? |
[dev-dependencies.proptest]
version = "$proptestVersion"
# The default feature set includes things like process forking which are not
# supported in Web Assembly.
default-features = false
# Enable using the `std` crate.
features = ["std"] It looks like by default protest uses some stuff that isn't available on wasm. Turning these features off might fix testing in wasm. How do I test for the wasm target so I can verify that this works? |
I think running those steps locally should do: https://github.com/Keats/jsonwebtoken/blob/master/.github/workflows/ci.yml#L75-L79 |
I'll give it a try in the morning |
Applied the changes - the wasm build doesn't seem to work for me locally but I'm getting a different error than the CI:
Given that this is happening in a build step and that this library already depends on ring (albeit a slightly earlier revision: 0.17.4) I'd imagine that this likely has more to do with my environment setup rather than the repo itself. EDIT: reading that error message again and given that the compiler being invoked here is CLANG - I wonder if the problem is that my CLANG out of the box isn't able to target wasm32-unknown-unknown EDIT: the problem is I'm on macOS and the default CLANG does not support wasm32-unknown-unknown |
Thanks! |
Adding an unknown variant to
KeyAlgorithm
to fix deserialization for future key algorithm variants.In my use case I have an Identity provider that is giving us a key in the JwkSet of type
ES512
which is currently not supported by the library. If even a single JWK in the JWKSet uses an algorithm that is not in the KeyAlgorithm enum it breaks deserialization of the entire JWKSet. I figure that by providing a catch-all variant in theKeyAlgorithm
enum it should be flexible enough to allow this library to properly deserialize JWKSets even if some of the variants use algorithms that the library doesn't yet support.