Let users chose what crypto backend of jsonwebtoken to use

[LukasKalbertodt]

Pull Request

What does this PR do?

jsonwebtoken was updated to 10.x in #717, but there, aws_lc_rs was unconditionally enabled. While I also prefer that backend, this library should probably leave the choice to users. I think my PR achieves exactly that, while still defaulting to aws_lc_rs.

PR checklist

Please check if your PR fulfills the following requirements:

• Does this PR fix an existing issue, or have you listed the changes applied in the PR description (and why they are needed)?
• Have you read the contributing guidelines?
• Have you made sure that the title is accurate and descriptive of the changes?

Thank you so much for contributing to Meilisearch!

Summary by CodeRabbit

• Chores

  • Updated jsonwebtoken dependency to v10.2.0.
  • Enhanced WASM32 support by expanding UUID handling.

• New Features

  • Added selectable JWT cryptographic backend feature flags (AWS-LC and Rust-Crypto).
  • Default feature set now includes AWS-LC cryptographic support.

[coderabbitai]

Walkthrough

Bumps jsonwebtoken to 10.2.0, adds jwt_aws_lc_rs and jwt_rust_crypto feature flags (enables jwt_aws_lc_rs by default), adds uuid for wasm32 targets, and removes a test-only Clone derive from TenantTokenClaim.

Changes

Cohort / File(s)	Summary
Dependency & feature updates Cargo.toml	Bumps jsonwebtoken from 10.0.0 to 10.2.0; removes aws_lc_rs feature from the non-wasm32 dependency entry; adds public features jwt_aws_lc_rs and jwt_rust_crypto; adds jwt_aws_lc_rs to default features; adds uuid (with v4, js, serde) under wasm32 target dependencies.
Struct derive cleanup src/tenant_tokens.rs	Removes the conditional #[cfg(test)] #[derive(Clone)] from the private TenantTokenClaim struct (no other fields or public API changes).

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

• Verify feature names map correctly to jsonwebtoken crate features and default features are updated as intended.
• Confirm wasm32 uuid features are correct and compatible.
• Ensure tests that relied on TenantTokenClaim: Clone are updated or unaffected.

Possibly related PRs

• chore: Bump jsonwebtoken crate to 10.0.0 #717 — touches jsonwebtoken version/features and the TenantTokenClaim conditional Clone derive; appears to make related adjustments.

Suggested labels

dependencies

Suggested reviewers

• curquiza

Poem

🐰
I hopped through Cargo.toml today,
Tweaked JWT flags along the way,
A Clone left quietly behind,
New UUIDs for wasm to find,
Hooray for tidy builds — hippity-hop hooray! 🎉

Pre-merge checks and finishing touches

✅ Passed checks (3 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title directly and clearly describes the main change: making the jsonwebtoken crypto backend configurable for users instead of being unconditionally locked to aws_lc_rs.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

✨ Finishing touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 1

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between e90a3c2 and 3378bff.

📒 Files selected for processing (2)

• Cargo.toml (2 hunks)
• src/tenant_tokens.rs (0 hunks)

💤 Files with no reviewable changes (1)

• src/tenant_tokens.rs

⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)

• GitHub Check: integration-tests

🔇 Additional comments (1)

Cargo.toml (1)

40-40: Good: UUID wasm32 target dependencies correctly include "js" feature.

Adding the "js" feature for uuid in wasm32 environments is appropriate for WASM runtimes that lack native random number generation. The feature set ["v4", "js", "serde"] aligns with browser-based contexts.

[coderabbitai]

Actionable comments posted: 0

🧹 Nitpick comments (1)

Cargo.toml (1)

49-50: Both crypto backend features can be enabled simultaneously; add a compile-time guard to prevent user confusion.

The claim is verified: jsonwebtoken v10.x requires exactly one crypto backend to be enabled. Currently, nothing prevents users from enabling both jwt_aws_lc_rs and jwt_rust_crypto in Cargo.toml simultaneously, which would trigger a compile error from jsonwebtoken itself.

Adding the suggested compile-time check in lib.rs is a good practice to provide early, clear feedback:

#[cfg(all(feature = "jwt_aws_lc_rs", feature = "jwt_rust_crypto"))]
compile_error!("features 'jwt_aws_lc_rs' and 'jwt_rust_crypto' are mutually exclusive; enable only one");

Alternatively, document the constraint prominently in the README so users understand they must choose one backend.

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 3378bff and cc25ab7.

📒 Files selected for processing (1)

• Cargo.toml (2 hunks)

⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)

• GitHub Check: integration-tests

🔇 Additional comments (2)

Cargo.toml (2)

36-36: ✅ Critical fix applied: hardcoded backend features removed.

The previous review flagged that line 36 unconditionally enabled features = ["aws_lc_rs"], defeating backend choice. This has been correctly fixed by removing the hardcoded features and relying on feature-gating instead.

---

40-40: Verify wasm32-specific uuid dependency override.

Line 40 defines uuid for wasm32 targets with extra features ["v4", "js"], while line 29 has the same crate for non-wasm with ["v4", "serde"]. Target-specific dependencies override non-target-specific ones, so on wasm32 the serde feature will be lost. Confirm this is intentional or add "serde" to line 40 if needed for consistency.

Also applies to: 29-29