Skip to content

4.13.0 - Add customizable JSON encoders and decoders
Compare
Choose a tag to compare
@gwynne gwynne released this 18 Jul 00:46
· 57 commits to main since this release
4.13.0
9e929d9
This commit was created on GitHub.com and signed with GitHub’s verified signature. The key has expired.
GPG key ID: 4AEE18F83AFDEB23
Expired
Learn about vigilant mode.

Add new, fully source-compatible APIs to JWTSigners and JWTSigner which allow specifying custom JSON encoders and decoders. Also provides the JWTJSONEncoder and JWTJSONDecoder protocols, which allow using alternative JSON implementations.

Custom coders specified for a single JWTSigner affect token parsing and signing performed only by that signer. Custom coders specified on a JWTSigners object will become the default coders for all signers added to that object, unless a given signer already specifies its own custom coders.

The default encoding and decoding implementation provided for JWTUnixEpochClaim (of which ExpirationClaim (exp), IssuedAtClaim (iat), and NotBeforeClaim (nbf) are examples) has been adjusted to encode and decode its Date value directly, rather than performing the explicit conversion to and from a Double. This allows these claims to take advantage of the dateEncodingStrategy and dateDecodingStrategy specified on custom JSON coders. (It also gives a bit of the lie to the name JWTUnixEpochClaim, but it's public API, so I left it alone.)

The default coders in use remain the same: An encoder and decoder which use the .secondsSince1970 date encoding/decoding strategy. As such, neither the new support nor the change to Date-based claims affects how tokens are signed or verified unless custom coders with different strategies are specified (that being, after all, the original need which inspired these changes).

Finally, an .integerSecondsSince1970 date encoding and decoding strategy has been added to the public API for the benefit of interoperation with JWT implementations - such as that used by GitHub - which require the aforementioned date-based claims to specify values as an integer number of seconds. (As GitHub proves, while this is in violation of the definition of NumericDate given by RFC 7519 § 2, which explicitly permits floating-point values, it nonetheless appears in the wild.)

This is a semver-minor release, as it adds new public API (although it has been careful to fully retain source compatibility, at the cost of a goodly amount of silly-looking repetition in the implementation - please, do not ask me if I know what default parameter values are! 😂).

Assets 2
Loading