feat: allow users to specify a custom header not defined in the struct

[jayakasadev]

• allow users to specify custom header values for token generation
• remove deprecated verify_slices_are_equal
• update tests

[rimutaka]

@jayakasadev , what is the use case for this?
Is extra a common name?
I could not find any references or examples in other implementations.

[jayakasadev]

I have a client which requires that I pass in some custom headers in the token. The extra field allows users to optionally add such headers.

[rimutaka]

@jayakasadev , are those headers essential to decoding and validating the token?
Can you provide a real life example?

[jayakasadev]

example: https://docs.cdp.coinbase.com/advanced-trade/docs/ws-auth
coinbase's auth requires a nonce header in the jwt token

[rimutaka]

@Keats , looks like there is an uncommon, but legit use case for this.
Are you open to merging it?
If yes, I'm happy to work with @jayakasadev to get it over the line (docs, probably more tests, code tidy up).

[jayakasadev]

@rimutaka let me know what changes are needed

[Keats]

Looks like clippy/cargo fmt needs to be ran

[rimutaka]

@jayakasadev , word of caution, I am not a maintainer, so feel free to ignore. The final word is with @Keats.

[jayakasadev]

@jayakasadev , word of caution, I am not a maintainer, so feel free to ignore. The final word is with @Keats.

understood. I wanted to ask if using a trait would be preferable. This way users who need a new field can define their own struct/impl without impacting existing users.

[jayakasadev]

I went ahead and implemented the trait approach in a separate branch in case
jayakasadev@32709ea

let me know if this approach is more desirable. The usage of Hashmap causes a small regression in performance. Traits does not.

[rimutaka]

Immediate thoughts: it's a breaking change and not sure if the existing tests cover all the affected parts.

[jayakasadev]

understood, im fine abandoning that approach if the performance regression is tolerable

     Running benches/jwt.rs (target/release/deps/jwt-10e1350ca031353b)
bench_encode            time:   [517.70 ns 520.80 ns 524.03 ns]
                        change: [+0.6197% +1.0974% +1.6803%] (p = 0.00 < 0.05)
                        Change within noise threshold.
Found 2 outliers among 100 measurements (2.00%)
  1 (1.00%) high mild
  1 (1.00%) high severe

bench_decode            time:   [919.45 ns 920.88 ns 922.50 ns]
                        change: [+4.8808% +5.1744% +5.4616%] (p = 0.00 < 0.05)
                        Performance has regressed.
Found 5 outliers among 100 measurements (5.00%)
  3 (3.00%) high mild
  2 (2.00%) high severe

this is on macos arm64

[rimutaka]

Why lifetime change?

[jayakasadev]

https://github.com/Keats/jsonwebtoken/actions/runs/13506827659/job/38042025098?pr=420

[rimutaka]

@jayakasadev, do you know if it's due to the new 1.85.0 elision rules?
I wonder if this change breaks pre-2024 editions.

[jayakasadev]

I can't say for sure. I don't have visibility into older runs on 1.84.0 or other 1.85.0 runs. If this came up for the first time, then I would hazard to guess that this is the case.

[jayakasadev]

In Rust 2024, all in-scope generic parameters, including lifetime parameters, are implicitly captured when the use<..> bound is not present.

https://doc.rust-lang.org/edition-guide/rust-2024/rpit-lifetime-capture.html

[jayakasadev]

https://medium.com/@TechSavvyScribe/understanding-lifetime-elision-in-rust-5df771c532f7#:~:text=There%20are%20three%20lifetime%20elision%20rules%20that,lifetime%20is%20assigned%20to%20all%20output%20reference

[rimutaka]

The GH actions run the tests against the MSRV here https://github.com/Keats/jsonwebtoken/blob/master/.github/workflows/ci.yml#L40
Can you manually run that workflow in your fork to see if it works?

[jayakasadev]

like this?
jayakasadev#1

[jayakasadev]

clippy is broken with

use of deprecated function `ring::deprecated_constant_time::verify_slices_are_equal`: To be removed. Internal function not intended for external use with no promises regarding side channels.
 --> src/crypto/mod.rs:1:26
  |
1 | use ring::constant_time::verify_slices_are_equal;
  |                          ^^^^^^^^^^^^^^^^^^^^^^^
  |
  = note: `-D deprecated` implied by `-D warnings`
  = help: to override `-D warnings` add `#[allow(deprecated)]`

I can look into fixing it in this pr, a separate one or mark it as ignored.

[jayakasadev]

@rimutaka @Keats are you still open to this pr being merged?

[rimutaka]

@jayakasadev , I'm not a maintainer and I'm not sure how much Vincent trusts my reviews :)
I'll give it another good look in the next few days anyway. Most likely early next week.
Thank you for putting in good work. 🙏

[jayakasadev]

thanks @rimutaka