Version 2.4.0

[florimondmanca]

2.4.0 - 2023-09-18

Removed

• Dropped support for Python 3.7, which has reached EOL. (Pull Upgrade tooling, including dealing w/ Python 3.7 EOL #247)

Added

• Add official support for Python 3.11. (Pull Upgrade tooling, including dealing w/ Python 3.7 EOL #247)

Fixed

• Use faster SHA512-based key hasher instead of password hashers. Reduces server load by making API key validation orders of magnitude faster (10x to 30x according to estimations, network latency aside). Hashed key will be transparently upgraded the first time .is_valid() is called. (Pull Use a fast key hasher instead of password hashers #244, Pull Remove code that updates the PK #251)
• Drop redundant .has_object_permission() implementation on BaseHasAPIKey when using DRF 3.14.0 or above. (Pull Drop redundant .has_object_permission impl on DRF 3.14.0 or above #240)

[codecov-commenter]

Codecov Report

Merging #248 (f5f7c99) into master (f93a1c4) will not change coverage.
The diff coverage is 100.00%.

❗ Your organization needs to install the Codecov GitHub app to enable full functionality.

@@            Coverage Diff            @@
##            master      #248   +/-   ##
=========================================
  Coverage   100.00%   100.00%           
=========================================
  Files           24        24           
  Lines          635       635           
=========================================
  Hits           635       635           

Files Changed	Coverage Δ
src/rest_framework_api_key/__init__.py	100.00% <100.00%> (ø)

📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more

[beda42]

👍

[florimondmanca]

Let's see if we might need an upgrade guide for 2.4 after all, considering #128 (comment)

[florimondmanca]

I'm tempted to make this a 3.0 release in line with what happened for 2.0 when Python and Django / DRF version support changed.

The SHA512 hasher and .has_object_permission() changes, although not-breaking, are also fairly significant, so it might be worth rolling a new major so that at least people with pinned dependencies can upgrade more consciously.

@davidfischer @beda42 Thoughts?

[beda42]

I think that it would make a lot of sense calling this 3.0.0. But in that case, maybe it would also make sense to change how the PK is created (that is for new objects only). Would using just the prefix be a problem? It seems like it has the role of a PK anyway...

It could have the same type and because it would only be used for new objects (old ones will keep current PK), no migration will be necessary.

[florimondmanca]

I think that it would make a lot of sense calling this 3.0.0. But in that case, maybe it would also make sense to change how the PK is created (that is for new objects only). Would using just the prefix be a problem? It seems like it has the role of a PK anyway...

Changing the PK only for new objects is a pretty interesting idea.

But I don’t think we need to block the release of the performance fix on also implementing the PK change.

I’d be okay if we release that later on, eg as a 4.0.

#252 suggests that releasing the perf improvement would relieve a lot of folks in the community.

I’ll make the changes to the docs to hint at using 3.*, then I think we can issue the release.

[florimondmanca]

Okay, closing to open a 3.0 release PR.