honeymoose
/
jjwt
mirror of https://github.com/jwtk/jjwt.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Updating changelog with more information/clarity for the 0.12.4 release (#907)

This commit is contained in:
lhazlewood 2024-01-26 21:23:18 -08:00 committed by GitHub
parent f61cfa875d
commit 26f5dc3dbb
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194
1 changed files with 53 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

54
CHANGELOG.md
View File

@ -2,8 +2,59 @@
### 0.12.4
This patch release:
This patch release includes various changes listed below.
#### Jackson Default Parsing Behavior
This release makes two behavioral changes to JJWT's default Jackson `ObjectMapper` parsing settings:
1. In the interest of having stronger standards to reject potentially malformed/malicious/accidental JSON that could
have undesirable effects on an application, JJWT's default `ObjectMapper `is now configured to explicitly reject/fail
parsing JSON (JWT headers and/or Claims) if/when that JSON contains duplicate JSON member names.
For example, now the following JSON, if parsed, would fail (be rejected) by default:
```json
{
"hello": "world",
"thisWillFail": 42,
"thisWillFail": "test"
}
```
Technically, the JWT RFCs _do allow_ duplicate named fields as long as the last parsed member is the one used
(see [JWS RFC 7515, Section 4](https://datatracker.ietf.org/doc/html/rfc7515#section-4)), so this is allowed.
However, because JWTs often reflect security concepts, it's usually better to be defensive and reject these
unexpected scenarios by default. The RFC later supports this position/preference in
[Section 10.12](https://datatracker.ietf.org/doc/html/rfc7515#section-10.12):
Ambiguous and potentially exploitable situations
could arise if the JSON parser used does not enforce the uniqueness
of member names or returns an unpredictable value for duplicate
member names.
Finally, this is just a default, and the RFC does indeed allow duplicate member names if the last value is used,
so applications that require duplicates to be allowed can simply configure their own `ObjectMapper` and use
that with JJWT instead of assuming this (new) JJWT default. See
[Issue #877](https://github.com/jwtk/jjwt/issues/877) for more.
2. If using JJWT's support to use Jackson to parse
[Custom Claim Types](https://github.com/jwtk/jjwt#json-jackson-custom-types) (for example, a Claim that should be
unmarshalled into a POJO), and the JSON for that POJO contained a member that is not represented in the specified
class, Jackson would fail parsing by default. Because POJOs and JSON data models can sometimes be out of sync
due to different class versions, the default behavior has been changed to ignore these unknown JSON members instead
of failing (i.e. the `ObjectMapper`'s `DeserializationFeature.FAIL_ON_UNKNOWN_PROPERTIES` is now set to `false`)
by default.
Again, if you prefer the stricter behavior of rejecting JSON with extra or unknown properties, you can configure
`true` on your own `ObjectMapper` instance and use that instance with the `Jwts.parser()` builder.
#### Additional Changes
This release also:
* Fixes a thread-safety issue when using `java.util.ServiceLoader` to dynamically lookup/instantiate pluggable
implementations of JJWT interfaces (e.g. JSON parsers, etc). See
[Issue #873](https://github.com/jwtk/jjwt/issues/873) and its documented fix in
[PR #893](https://github.com/jwtk/jjwt/pull/892).
* Ensures Android environments and older `org.json` library usages can parse JSON from a `JwtBuilder`-provided
`java.io.Reader` instance. [Issue 882](https://github.com/jwtk/jjwt/issues/882).
* Ensures a single string `aud` (Audience) claim is retained (without converting it to a `Set`) when copying/applying a
@ -14,6 +65,7 @@ This patch release:
[6.2.1.3](https://datatracker.ietf.org/doc/html/rfc7518#section-6.2.1.3), and
[6.2.2.1](https://datatracker.ietf.org/doc/html/rfc7518#section-6.2.2.1), respectively.
[Issue 901](https://github.com/jwtk/jjwt/issues/901).
* Fixes various typos in documentation and JavaDoc. Thanks to those contributing pull requests for these!
### 0.12.3