Hi,

I need to decode the JWT to get the content, and in some context I don't care about whether it's properly signed or not. But decode_segments is private.

Could you please make decode_segments public?

Regards,

Fixes #30

Besides fixing the README file, I thought to also add some documentation as tests, so they'll appear in docs.rs - let's make 2019 the year of well documented libraries in Rust :^)

I did run rustfmt (automatically run-on-save on my setup) over the code and committed some linting aside, up to you to cherry pick or merge everything.

Opinions @GildedHonour ?

Thanks for evaluating this patch! :+1:

At the moment, it is not possible to create a payload of, for instance:

{
"sub": "1234567890",
"name": "John Doe",
"admin": true
"exp": 123545679
}

My system has OpenSSL 1.1.1, and openssl crate 0.9 doesn't work with it. Check out the related issue here:

https://github.com/sfackler/rust-openssl/issues/987

That issue has been linked to several other issues like this one for crates with the same issue as frank_jwt.

Thanks!

I've looked through the source code, and while the readme claims that it checks all registered jwt claims

There's nothing in the code that actually does that. the readme should be updated with this, so as not to confuse users

• [x] HS256
• [x] HS384
• [x] HS512
• [x] RS256
• [x] RS384
• [x] RS512
• [x] ES256
• [x] ES384
• [x] ES512
• [x] Sign
• [x] Verify
• [ ] iss (issuer) check
• [ ] sub (subject) check
• [ ] aud (audience) check
• [ ] exp (expiration time) check
• [ ] nbf (not before time) check
• [ ] iat (issued at) check
• [ ] jti (JWT id) check

ДД Создаем коллекцию NFT Ищем разработчика для создания сайта для минта (смарт контракт) и все необходимое для успешного выпуска коллекции в OpenSea на ETH

According to semver one should bump major version when introducing incompatible API changes. #59 introduced breaking changes and thus broke others code. Thanks!

Currently the Error type used in the crate doesn't implement std::error::Error. This degrades ergonomics when used elsewhere. Upgrading to use failure would improve things.

At the moment for the RS algorithms the function encode expects a path to a private pem file rather than a structure representing a private pem file itself. Should it be changed, leave your comment.

In some cases r and/or s may be less than 32 bytes long, which caused the code that builds the full signature to attempt to splice after the end of signature and panic.

Header

{
  "alg": "HS256",
  "typ": "JWT"
}

Payload

{
  "userid": "CRISP",
  "group": "ATI",
  "resources": []
}

secret: "secret"

Should generate (using jwt.io):

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VyaWQiOiJDUklTUCIsImdyb3VwIjoiQVRJIiwicmVzb3VyY2VzIjpbXX0.K9nfZnbMzF1-P1zXEQHeYYUz35NTbTPpT560wNG16DM

This lib returns:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJncm91cCI6IkFUSSIsInJlc291cmNlcyI6W10sInVzZXJpZCI6IkNSSVNQIn0=.XfroJa5E41zs03U1aPtP3Qy3Er4vIBVb0Be
tZ0GuBfk=

Even removing trailing = characters (#28) , this JWT is not valid.