Jackson chooses the target type for JSON numbers based on their value,
while deserializing without correct typing information present.
This leads to a confusing behavior:
String token = Jwts.builder()
.claim("byte", (byte) 42)
.claim("short", (short) 42)
.claim("int", 42)
.claim("long_small", (long) 42)
.claim("long_big", ((long) Integer.MAX_VALUE) + 42)
.compact();
Claims claims = (Claims) Jwts.parser().parse(token).getBody();
claims.get("int", Integer.class); // => 42
claims.get("long_big", Long.class); // => ((long) Integer.MAX_VALUE) + 42
claims.get("long_small", Long.class); // throws RequiredTypeException: required=Long, found=Integer
claims.get("short", Short.class); // throws RequiredTypeException: required=Short, found=Integer
claims.get("byte", Byte.class); // throws RequiredTypeException: required=Byte, found=Integer
With this commit, `DefaultClaims.getClaim(String, Class<T>)` will
correctly handle cases when required type is `Long`, `Integer`, `Short`
or `Byte`: check that value fits in the required type and cast to it.
// ... setup is the same as above
claims.get("int", Integer.class); // => 42
claims.get("long_big", Long.class); // => ((long) Integer.MAX_VALUE) + 42
claims.get("long_small", Long.class); // => (long) 42
claims.get("short", Short.class); // => (short) 42
claims.get("byte", Byte.class); // => (byte) 42
Fixes#142.
re-use buffer instead of creating new ones
avoid creating unneeded buffers in the Strings util methods
Stop continuously copying array with StringBuilder#deleteCharAt
work directly on StringBuilder instead of creating a temporary String
test added to cover the modified methods
Quite possible we're missing something here, so please forgive if so. After seeing [this article](https://auth0.com/blog/2015/03/31/critical-vulnerabilities-in-json-web-token-libraries/) (see "RSA or HMAC?" section), we did a quick scan through the JJWT implementation to see if it was vulnerable. While it seems like the RSA check should work, no such check seemed to exist for ECDSA signatures.
As a result, it may be possible for users of this library to use `setSigningKey(byte[] key)` while intending to use ECDSA, but have the client alter the algorithm and signature to use HMAC with the public key as the "secret key", allowing the client to inject arbitrary payloads.
cc @thomaso-mirodin
Micah Silverman
Aaron Wood
Les Hazlewood
Robert Erdin
sainaen
benoit
Michael Sims
Martin Treurnicht
Alexander Kjäll
Brian Matzon
Aaron Davidson
Mitchell Morris
josebarrueta
Jason Erickson