All notable changes to this project will be documented in this file.
The format is based on Keep a Changelog. This project adheres to Semantic Versioning.
NOTE: this release drops compatibility with certain Python and Django versions, but contains no other breaking changes. See Upgrade to 2.0 for detailed migration steps.
- Dropped support for Django 2.0 and Django 2.1. (Pull #126)
- Dropped support for Python 3.5. (Pull #84)
- Add support for Django 3.0. (Pull #82)
- Add support for Python 3.8. (Pull #81)
- Add
BaseAPIKeyManager.get_from_key()
to allow retrieving API keys from views. (Pull #93) - Add type annotations, and partial support for
django-stubs
anddjangorestframework-stubs
. (Pull #88, Pull #122)
- Now ships with type annotations (PEP 561). (Pull #73)
NOTE: this release contains migrations. See Upgrade to v1.4 for detailed instructions.
- The
prefix
andhashed_key
are now stored in dedicated fields on theAPIKey
model. (Pull #62)
NOTE: this release contains migrations. In your Django project, run them using:
python manage.py migrate rest_framework_api_key
- Add abstract API key model (
AbstractAPIKey
) and base manager (BaseAPIKeyManager
). (Pull #36) - Add base permissions (
BaseHasAPIKey
). (Pull #46)
- The
id
field ofAPIKey
is now non-editable
. APIKeyModelAdmin
does not definefieldsets
anymore. This allows subclasses to benefit from Django's automatic fieldsets. (Pull #52)
- Explicitly use
utf-8
encoding insetup.py
, which could previously lead to issues when installing on certain systems. (Pull #58)
- Fixed a critical bug in
APIKeyModelAdmin
that preventedrest_framework_api_key
from passing Django system checks. (Pull #39)
NOTE: this release contains migrations. In your Django project, run them using:
python manage.py migrate rest_framework_api_key
- API keys can now have an optional
expiry_date
. (Pull #33)HasAPIKey
denies access if the API key has expired, i.e. ifexpiry_date
, if set, is in the past. - It is now possible to search by
prefix
in the API key admin panel. - The
prefix
is now displayed in the edit view of the API key admin panel.
- Improve documentation on which password hasher is used.
- Add tests against the Argon2, BcryptSHA256 and PBKDF2SHA1 hashers. (Pull #32)
- Fix support for password hashers that generate hashes that contain dots. (Pull #31)
This release is incompatible with 0.x. See Upgrade to 1.0 for migration steps.
- Remove
HasAPIKeyOrIsAuthenticated
permission class. You should use bitwise composition now, e.g.HasAPIKey | IsAuthenticated
. - Drop the
DRF_API_KEY_*
settings. (Pull #19)
- Switch to a new API key generation and validation scheme. Clients must now authorize using a single API key header (Pull #19). The header is
Authorization
by default. It can be customized using theAPI_KEY_CUSTOM_HEADER
setting (Pull #26). Use thename
field to identify clients.
- Add support for Django 2.2. (Pull #27)
- Add programmatic API key creation using
APIKey.objects.create_key()
. (Pull #19)
- Improved API key storage using Django's password hashing helpers. (Uses the default Django password hasher.) (Pull #19)
- Drop support for Python 3.4. Only 3.5, 3.6 and 3.7 are supported now.
- Drop support for Django < 2.0. Only 2.0 and 2.1 are supported now.
HasAPIKey
now implements.has_object_permissions()
, which allows to compose it with other permission classes and perform object-level permission checks. (Pull #25)
Initial changelog entry.
APIKey
model.HasAPIKey
andHasAPIKeyOrIsAuthenticated
permission classes.- Generate, view and revoke API keys from the Django admin.
- Authenticate requests using the
Api-Token
andApi-Secret-Key
headers. Customizable via theDRF_API_KEY_TOKEN_HEADER
andDRF_API_KEY_SECRET_KEY_HEADER
settings.