feat: Add insecure_decode_without_signature_validation #418
Conversation
| /// ``` | ||
| pub fn insecure_decode_without_signature_validation<T: DeserializeOwned>( | ||
| token: &str, | ||
| validation: &Validation, |
There was a problem hiding this comment.
I'm missing something here. Please ignore if I'm wrong.
The function says it does not do validation and the algorithm can be arbitrary chose, yet, there is a validation param and the validation step. So it's kind of partial validation.
I find it confusing and is not what #401 calls for.
There was a problem hiding this comment.
Ah i was not completely sure that was the case as the creator of the issue wanted essentially this API:
let mut validation = jsonwebtoken::Validation::insecure_without_signature_validation();
let payload = jsonwebtoken::insecure_decode_without_signature_validation::<Claims>(token, &validation).unwrap();And IMO then a Validation::insecure_none or similar should exist to make this function more general.
Nonetheless the Doc comment is wrong so thanks for pointing that out!
| let (claims, _) = expect_two!(rest.rsplitn(2, '.')); | ||
| let decoded_claims = DecodedJwtPartClaims::from_jwt_part_claims(claims)?; | ||
| let claims = decoded_claims.deserialize()?; | ||
| validate(decoded_claims.deserialize()?, validation)?; |
There was a problem hiding this comment.
The function description says "the claims are not validated", but they are.
| token: &str, | ||
| validation: &Validation, | ||
| ) -> Result<T> { | ||
| let (_, rest) = expect_two!(token.rsplitn(2, '.')); |
There was a problem hiding this comment.
JWT has 3 parts: Header, Payload, Signature.
The existing code refers to them by those names:
let (signature, message) = expect_two!(token.rsplitn(2, '.'));
let (payload, header) = expect_two!(message.rsplitn(2, '.'));
It would be good to keep them consistent throughout the file.
Nereuxofficial
force-pushed
the
feat/insecure-decode-without-signature-validation
branch
from
84d5492 to
a083324
Compare
|
Can I help out to move this forward? |
Feel free to do so as i no longer have a use-case for this feature and the envisioned API is a bit unclear. |
|
While looking into this, I found that |
As discussed here adds support for insecure_decode_without_serialization as well as a doc test for it. I also fixed some doc warnings while at it.