Skip to content

Commit

Permalink
October-30-2022:Jazz master branch merge (#15)
Browse files Browse the repository at this point in the history 
* Fix ES locale translation error (jazzband#499)

* chore: test on Django 4.0 (jazzband#495)

* chore: test on Django 4.0

* Remove Django 3.1 support from trove

* Remove Django 3.1 from tox

* Remove 3.1 reference in tox.ini

Co-authored-by: Andrew Chen Wang <[email protected]>

* Stop deleting blacklist on user delete (jazzband#516)

* OutstandingToken user on_delete should be null

* Add test to verify that deleting a User doesn't remove tokens from the blacklist

This is a rather unexpected default behavior. Deleting a User means that
their blacklisted tokens become live again.

* Add migration for cascading User deletion to SET_NULL instead of DELETE

* [pre-commit.ci] auto fixes from pre-commit.com hooks

for more information, see https://pre-commit.ci

Co-authored-by: Andrew Chen Wang <[email protected]>
Co-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com>

* [pre-commit.ci] pre-commit autoupdate (jazzband#498)

updates:
- [github.com/pre-commit/pre-commit-hooks: v4.0.1 → v4.1.0](pre-commit/pre-commit-hooks@v4.0.1...v4.1.0)
- [github.com/asottile/yesqa: v1.2.3 → v1.3.0](asottile/yesqa@v1.2.3...v1.3.0)
- [github.com/pycqa/isort: 5.9.3 → 5.10.1](PyCQA/isort@5.9.3...5.10.1)
- [github.com/psf/black: 21.9b0 → 21.12b0](psf/black@21.9b0...21.12b0)
- [github.com/pre-commit/pre-commit-hooks: v4.0.1 → v4.1.0](pre-commit/pre-commit-hooks@v4.0.1...v4.1.0)
- [github.com/asottile/pyupgrade: v2.28.0 → v2.31.0](asottile/pyupgrade@v2.28.0...v2.31.0)

Co-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com>

* Enable ECDSA algorithms supported by PyJWT (jazzband#520)

* Parameterize some tests to reduce duplication and make it easy to add more algorithms

This way new algorithms can be added to the basic test set simply by
adding their backends to TestTokenBackend.backends.

* Enable ECDSA algorithms supported by PyJWT

Enable the algorithms and add basic tests for them.

Also convert the ALLOWED_ALGORITHMS constant to a set for a minor style
cleanup.

* [pre-commit.ci] auto fixes from pre-commit.com hooks

for more information, see https://pre-commit.ci

Co-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com>

* Simplify using custom token classes in serializers (jazzband#517)

For most cases this could be done by overriding get_token, which is simple
enough. The exception was TokenRefreshSerializer.validate where the entire
method needed to be copy-pasted to allow using a custom replacement for
RefreshToken. The other cases are changed the same way mainly for
consistency.

* [pre-commit.ci] pre-commit autoupdate (jazzband#524)

updates:
- [github.com/psf/black: 21.12b0 → 22.1.0](psf/black@21.12b0...22.1.0)

Co-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com>

* Make the token serializer configurable (jazzband#521)

* Update translation files (jazzband#526)

* Add default __getattr__ behavior to models.TokenUser (jazzband#528)

* Add default __getattr__ behavior to models.TokenUser to allow getting custom claims defined in serializers

* [pre-commit.ci] auto fixes from pre-commit.com hooks

for more information, see https://pre-commit.ci

Co-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com>

* Allow overriding access token class (jazzband#529)

* Maintain compatibility with serializer_class overrides (jazzband#530)

* Consider leeway when checking expiry (jazzband#458)

* Add locale checker to CI (jazzband#456)

* Add locale checker to CI

* Just pip install Django

* Add gettext package to OS

* Add sudo to apt-get

* Use @2ykwang 's updated script

* [pre-commit.ci] auto fixes from pre-commit.com hooks

for more information, see https://pre-commit.ci

* Only update on push to master
* To avoid pain points of PRs and histories being split
* Trying to use Andrew's username for pushing to see if that works

* Use separate workflow file

Co-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com>

* Update CHANGELOG.md for v5.1.0 (jazzband#527)

* Update CHANGELOG.md for v5.0.1

* Update CHANGELOG.md

* Remove looking for maintainers in README since Jazzband

Co-authored-by: Andrew Chen Wang <[email protected]>

* Fix i18n CI (jazzband#538)

* Open PR on i18n (jazzband#539)

* fix small typo (jazzband#540)

* Setup initial PyJWT 1.7.1 support (jazzband#536)

* Fix release locale checker (jazzband#541)

* Update locale files (jazzband#542)

* [pre-commit.ci] pre-commit autoupdate (jazzband#545)

updates:
- [github.com/asottile/pyupgrade: v2.31.0 → v2.31.1](asottile/pyupgrade@v2.31.0...v2.31.1)

Co-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com>

* Remove the JWTTokenUserAuthentication from the Experimental Features jazzband#546 (jazzband#547)

* Change from git protocol to https protocol (jazzband#555)

* [pre-commit.ci] pre-commit autoupdate (jazzband#551)

updates:
- [github.com/psf/black: 22.1.0 → 22.3.0](psf/black@22.1.0...22.3.0)

Co-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com>

* Fix leeway type error (jazzband#554)

* Fix lewway type error

* Add test case

* Update Korean translation

* Add type hints

* [pre-commit.ci] auto fixes from pre-commit.com hooks

for more information, see https://pre-commit.ci

* Fix translation

revert POT-Creation-Date

* update translation

Co-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com>

* [pre-commit.ci] pre-commit autoupdate (jazzband#557)

* Add info on TokenBlacklistView to the docs (jazzband#558)

* chore(ci): add informational Codecov status checks (jazzband#559)

* Update JWTStatelessUserAuthentication docs (jazzband#561)

* Allow none jti claim token type claim (jazzband#567)

* Allow customizing token JSON encoding (jazzband#568)

* Allow specifying custom JSONEncoder for TokenBackend

* Make TokenBackend JSONEncoder configurable

* [pre-commit.ci] pre-commit autoupdate (jazzband#571)

updates:
- [github.com/asottile/pyupgrade: v2.32.0 → v2.32.1](asottile/pyupgrade@v2.32.0...v2.32.1)

Co-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com>

* Update CHANGELOG to 5.2.0 (jazzband#573)

* Locale update (jazzband#574)

* update & correct supported versions in docs (jazzband#576)

* update & correct supported versions in docs

* Add DRF supported version

Co-authored-by: Andrew Chen Wang <[email protected]>

* Add Swedish translations (jazzband#579)

* Fixed issue jazzband#543 (jazzband#586)

* Allow optional installation of the 'cryptography' package (jazzband#543)

* Update docs (jazzband#543)

* Update docs (jazzband#543)

* Update docs/getting_started.rst

Co-authored-by: Andrew Chen Wang <[email protected]>

* fix for code-block (jazzband#543)

* another fix for code-block (jazzband#543)

* fix: removed extra line (jazzband#543)

Co-authored-by: Andrew Chen Wang <[email protected]>

* [pre-commit.ci] pre-commit autoupdate (jazzband#587)

updates:
- [github.com/pre-commit/pre-commit-hooks: v4.2.0 → v4.3.0](pre-commit/pre-commit-hooks@v4.2.0...v4.3.0)
- [github.com/pre-commit/pre-commit-hooks: v4.2.0 → v4.3.0](pre-commit/pre-commit-hooks@v4.2.0...v4.3.0)
- [github.com/asottile/pyupgrade: v2.32.1 → v2.34.0](asottile/pyupgrade@v2.32.1...v2.34.0)

Co-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com>

* [pre-commit.ci] pre-commit autoupdate (jazzband#589)

updates:
- [github.com/psf/black: 22.3.0 → 22.6.0](psf/black@22.3.0...22.6.0)

Co-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com>

* [pre-commit.ci] pre-commit autoupdate (jazzband#590)

* [pre-commit.ci] pre-commit autoupdate (jazzband#594)

updates:
- [github.com/asottile/pyupgrade: v2.37.1 → v2.37.2](asottile/pyupgrade@v2.37.1...v2.37.2)

Co-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com>

* [pre-commit.ci] pre-commit autoupdate (jazzband#597)

updates:
- [github.com/asottile/pyupgrade: v2.37.2 → v2.37.3](asottile/pyupgrade@v2.37.2...v2.37.3)

Co-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com>

* [pre-commit.ci] pre-commit autoupdate (jazzband#601)

updates:
- [github.com/asottile/yesqa: v1.3.0 → v1.4.0](asottile/yesqa@v1.3.0...v1.4.0)

Co-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com>

* Fix uncaught exception with JWK (jazzband#600)

* Fix uncaught exception with JWK

* [pre-commit.ci] auto fixes from pre-commit.com hooks

for more information, see https://pre-commit.ci

* Allow tests to run on older JWT versions

Co-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com>

* Test on Django 4.1 (jazzband#604)

* [pre-commit.ci] pre-commit autoupdate (jazzband#609)

* Add v5.2.1 changes (jazzband#611)

* use non-deprecated UTC timezone (jazzband#606)

RemovedInDjango50Warning

* Added Romanian translations (jazzband#591)

* Added Romanian translations

* Changed some translations according to the grammatical rules of the Romanian language

* Changed some translations according to the advices of:
https://github.com/marcellefter
https://github.com/uoxiu

Co-authored-by: Daniel Cuznetov <[email protected]>

* allow verification skipping (jazzband#605)

* allow verify

skip verification if VERIFYING_KEY is not set

* Update settings.py

* Update authentication.py

* Update settings.py

* Update authentication.py

* [pre-commit.ci] pre-commit autoupdate (jazzband#619)

* [pre-commit.ci] pre-commit autoupdate (jazzband#620)

* Update locale files (jazzband#624)

* Revert 605 (jazzband#629)

* [pre-commit.ci] pre-commit autoupdate (jazzband#630)

* [Docs] Fix typo in blacklist_app.rst (jazzband#593)

* Fix typo in blacklist_app.rst

`TokenBlackListView` -> `TokenBlacklistView`

* Append CHANGELOG

Co-authored-by: Andrew-Chen-Wang <[email protected]>

Co-authored-by: Marc Salat <[email protected]>
Co-authored-by: Christofer Bertonha <[email protected]>
Co-authored-by: Andrew Chen Wang <[email protected]>
Co-authored-by: vainu-arto <[email protected]>
Co-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com>
Co-authored-by: yeongkwang <[email protected]>
Co-authored-by: Oscar Y Chen <[email protected]>
Co-authored-by: totycro <[email protected]>
Co-authored-by: Byron Motoche <[email protected]>
Co-authored-by: Vladimir <[email protected]>
Co-authored-by: Tom Hu <[email protected]>
Co-authored-by: Dennis Dinwiddie <[email protected]>
Co-authored-by: abdurrahman <[email protected]>
Co-authored-by: Pasindu Prabhashitha <[email protected]>
Co-authored-by: Armenak Baburyan <[email protected]>
Co-authored-by: Jeremy Mayeres <[email protected]>
Co-authored-by: Benedikt S. Vogler <[email protected]>
Co-authored-by: Daniel Cuzneţov <[email protected]>
Co-authored-by: Daniel Cuznetov <[email protected]>
Co-authored-by: Domenico <[email protected]>
Co-authored-by: Boseong Choi <[email protected]>
Co-authored-by: Andrew-Chen-Wang <[email protected]>
  • Loading branch information
@eadwinCode @Pijuli
@bertonha @Andrew-Chen-Wang @vainu-arto @pre-commit-ci @2ykwang @oscarychen @totycro @byrpatrick @inti7ary @thomasrockhu-codecov @mrdinwiddie @asaah18 @pasindu-pr @armenak-baburyan @jerr0328 @BSVogler @DCDie @domdinicola @cbscsm
23 people authored Oct 30, 2022
1 parent bfcb427 commit a96c525
Show file tree
Hide file tree
Showing 28 changed files with 452 additions and 271 deletions.
14 changes: 14 additions & 0 deletions CHANGELOG.md
View file
Original file line number Diff line number Diff line change
@@ -1,5 +1,19 @@
## Unreleased

## Version 5.2.2

Major security release

* Revert #605 in https://github.com/jazzband/djangorestframework-simplejwt/pull/629
* Fix typo in blacklist_app.rst by @cbscsm in https://github.com/jazzband/djangorestframework-simplejwt/pull/593

## Version 5.2.1

* Add Swedish translations by @PasinduPrabhashitha in https://github.com/jazzband/djangorestframework-simplejwt/pull/579
* Fixed issue #543 by @armenak-baburyan in https://github.com/jazzband/djangorestframework-simplejwt/pull/586
* Fix uncaught exception with JWK by @jerr0328 in https://github.com/jazzband/djangorestframework-simplejwt/pull/600
* Test on Django 4.1 by @2ykwang in https://github.com/jazzband/djangorestframework-simplejwt/pull/604

## Version 5.2.0

* Remove the JWTTokenUserAuthentication from the Experimental Features #546 by @byrpatrick in https://github.com/jazzband/djangorestframework-simplejwt/pull/547
Expand Down
23 changes: 0 additions & 23 deletions docs/experimental_features.md
View file

This file was deleted.

16 changes: 16 additions & 0 deletions docs/getting_started.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -97,3 +97,19 @@ curl \
...
{"access":"eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VyX3BrIjoxLCJ0b2tlbl90eXBlIjoiYWNjZXNzIiwiY29sZF9zdHVmZiI6IuKYgyIsImV4cCI6MTIzNTY3LCJqdGkiOiJjNzE4ZTVkNjgzZWQ0NTQyYTU0NWJkM2VmMGI0ZGQ0ZSJ9.ekxRxgb9OKmHkfy-zs1Ro_xs1eMLXiR17dIDBVxeT-w"}
```
Cryptographic Dependencies (Optional)
-------------------------------------
If you are planning on encoding or decoding tokens using certain digital
signature algorithms (i.e. RSA and ECDSA; visit PyJWT for other algorithms), you will need to install the
cryptography_ library. This can be installed explicitly, or as a required
extra in the `django-ninja-jwt` requirement:
pip install django-ninja-jwt[crypto]
The `django-ninja-jwt[crypto]` format is recommended in requirements
files in projects using `Ninja JWT`, as a separate `cryptography` requirement
line may later be mistaken for an unused requirement and removed.
[cryptography](https://cryptography.io)
274 changes: 138 additions & 136 deletions docs/settings.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -57,192 +57,194 @@ are valid. This `timedelta` value is added to the current UTC time
during token generation to obtain the token's default `exp` claim
value.

`ROTATE_REFRESH_TOKENS`
=======================
``BLACKLIST_AFTER_ROTATION``
----------------------------

When set to `True`, if a refresh token is submitted to the
`TokenRefreshView`, a new refresh token will be returned along with the
new access token. This new refresh token will be supplied via a
`refresh` key in the JSON response. New refresh tokens will have a
renewed expiration time which is determined by adding the timedelta in
the `REFRESH_TOKEN_LIFETIME` setting to the current time when the
request is made. If the blacklist app is in use and the
`BLACKLIST_AFTER_ROTATION` setting is set to `True`, refresh tokens
submitted to the refresh view will be added to the blacklist.

`BLACKLIST_AFTER_ROTATION`
==========================

When set to `True`, causes refresh tokens submitted to the
`TokenRefreshView` to be added to the blacklist if the blacklist app is
in use and the `ROTATE_REFRESH_TOKENS` setting is set to `True`. You
need to add `'ninja_jwt.token_blacklist',` to your `INSTALLED_APPS` in
the settings file to use this setting.
When set to ``True``, causes refresh tokens submitted to the
``TokenRefreshView`` to be added to the blacklist if the blacklist app is in
use and the ``ROTATE_REFRESH_TOKENS`` setting is set to ``True``.
You need to add ``'ninja_jwt.token_blacklist',`` to your
``INSTALLED_APPS`` in the settings file to use this setting.

Learn more about `/blacklist_app`{.interpreted-text role="doc"}.

`UPDATE_LAST_LOGIN`
===================

When set to `True`, last_login field in the auth_user table is updated
upon login (TokenObtainPairController).
When set to ``True``, last_login field in the auth_user table is updated upon
login (TokenObtainPairView).

> Warning: Updating last_login will dramatically increase the number of
> database transactions. People abusing the views could slow the server
> and this could be a security vulnerability. If you really want this,
> throttle the endpoint.
Warning: Updating last_login will dramatically increase the number of database
transactions. People abusing the views could slow the server and this could be
a security vulnerability. If you really want this, throttle the endpoint with
DRF at the very least.

`ALGORITHM`
===========

The algorithm from the PyJWT library which will be used to perform
signing/verification operations on tokens. To use symmetric HMAC signing
and verification, the following algorithms may be used: `'HS256'`,
`'HS384'`, `'HS512'`. When an HMAC algorithm is chosen, the
`SIGNING_KEY` setting will be used as both the signing key and the
verifying key. In that case, the `VERIFYING_KEY` setting will be
ignored. To use asymmetric RSA signing and verification, the following
algorithms may be used: `'RS256'`, `'RS384'`, `'RS512'`. When an RSA
algorithm is chosen, the `SIGNING_KEY` setting must be set to a string
that contains an RSA private key. Likewise, the `VERIFYING_KEY` setting
must be set to a string that contains an RSA public key.
signing/verification operations on tokens. To use symmetric HMAC signing and
verification, the following algorithms may be used: ``'HS256'``, ``'HS384'``,
``'HS512'``. When an HMAC algorithm is chosen, the ``SIGNING_KEY`` setting
will be used as both the signing key and the verifying key. In that case, the
``VERIFYING_KEY`` setting will be ignored. To use asymmetric RSA signing and
verification, the following algorithms may be used: ``'RS256'``, ``'RS384'``,
``'RS512'``. When an RSA algorithm is chosen, the ``SIGNING_KEY`` setting must
be set to a string that contains an RSA private key. Likewise, the
``VERIFYING_KEY`` setting must be set to a string that contains an RSA public
key.

`SIGNING_KEY`
=============

The signing key that is used to sign the content of generated tokens.
For HMAC signing, this should be a random string with at least as many
bits of data as is required by the signing protocol. For RSA signing,
this should be a string that contains an RSA private key that is 2048
bits or longer. Since Ninja JWT defaults to using 256-bit HMAC signing,
the `SIGNING_KEY` setting defaults to the value of the `SECRET_KEY`
setting for your django project. Although this is the most reasonable
default that Ninja JWT can provide, it is recommended that developers
change this setting to a value that is independent from the django
project secret key. This will make changing the signing key used for
The signing key that is used to sign the content of generated tokens. For HMAC
signing, this should be a random string with at least as many bits of data as
is required by the signing protocol. For RSA signing, this should be a string
that contains an RSA private key that is 2048 bits or longer. Since Simple JWT
defaults to using 256-bit HMAC signing, the ``SIGNING_KEY`` setting defaults to
the value of the ``SECRET_KEY`` setting for your django project. Although this
is the most reasonable default that Simple JWT can provide, it is recommended
that developers change this setting to a value that is independent from the
django project secret key. This will make changing the signing key used for
tokens easier in the event that it is compromised.

`VERIFYING_KEY`
===============

The verifying key which is used to verify the content of generated
tokens. If an HMAC algorithm has been specified by the `ALGORITHM`
setting, the `VERIFYING_KEY` setting will be ignored and the value of
the `SIGNING_KEY` setting will be used. If an RSA algorithm has been
specified by the `ALGORITHM` setting, the `VERIFYING_KEY` setting must
be set to a string that contains an RSA public key.
The verifying key which is used to verify the content of generated tokens. If
an HMAC algorithm has been specified by the ``ALGORITHM`` setting, the
``VERIFYING_KEY`` setting will be ignored and the value of the ``SIGNING_KEY``
setting will be used. If an RSA algorithm has been specified by the
``ALGORITHM`` setting, the ``VERIFYING_KEY`` setting must be set to a string
that contains an RSA public key.

`AUDIENCE`
==========

The audience claim to be included in generated tokens and/or validated
in decoded tokens. When set to `None`, this field is excluded from
tokens and is not validated.
The audience claim to be included in generated tokens and/or validated in
decoded tokens. When set to ``None``, this field is excluded from tokens and is
not validated.

`ISSUER`
========

The issuer claim to be included in generated tokens and/or validated in
decoded tokens. When set to `None`, this field is excluded from tokens
and is not validated.
The issuer claim to be included in generated tokens and/or validated in decoded
tokens. When set to ``None``, this field is excluded from tokens and is not
validated.

`JWK_URL`
=========
The JWK_URL is used to dynamically resolve the public keys needed to
verify the signing of tokens. When using Auth0 for example you might set
this to '<https://yourdomain.auth0.com/.well-known/jwks.json>'. When
set to `None`, this field is excluded from the token backend and is not
used during validation.
``JWK_URL``
----------

`LEEWAY`
========
The JWK_URL is used to dynamically resolve the public keys needed to verify the
signing of tokens. When using Auth0 for example you might set this to
'https://yourdomain.auth0.com/.well-known/jwks.json'. When set to ``None``,
this field is excluded from the token backend and is not used during
validation.

Leeway is used to give some margin to the expiration time. This can be
an integer for seconds or a `datetime.timedelta`. Please reference
<https://pyjwt.readthedocs.io/en/latest/usage.html#expiration-time-claim-exp>
``LEEWAY``
----------

Leeway is used to give some margin to the expiration time. This can be an
integer for seconds or a ``datetime.timedelta``. Please reference
https://pyjwt.readthedocs.io/en/latest/usage.html#expiration-time-claim-exp
for more information.

`USER_ID_FIELD`
===============
``AUTH_HEADER_TYPES``
---------------------

The database field from the user model that will be included in
generated tokens to identify users. It is recommended that the value of
this setting specifies a field that does not normally change once its
initial value is chosen. For example, specifying a `username` or
`email` field would be a poor choice since an account's username or
email might change depending on how account management in a given
service is designed. This could allow a new account to be created with
an old username while an existing token is still valid which uses that
username as a user identifier.

`USER_ID_CLAIM`
===============
The authorization header type(s) that will be accepted for views that require
authentication. For example, a value of ``'Bearer'`` means that views
requiring authentication would look for a header with the following format:
``Authorization: Bearer <token>``. This setting may also contain a list or
tuple of possible header types (e.g. ``('Bearer', 'JWT')``). If a list or
tuple is used in this way, and authentication fails, the first item in the
collection will be used to build the "WWW-Authenticate" header in the response.

The claim in generated tokens which will be used to store user
identifiers. For example, a setting value of `'user_id'` would mean
generated tokens include a `user_id` claim that contains the user's
identifier.
``AUTH_HEADER_NAME``
----------------------------

`USER_AUTHENTICATION_RULE`
==========================
The authorization header name to be used for authentication.
The default is ``HTTP_AUTHORIZATION`` which will accept the
``Authorization`` header in the request. For example if you'd
like to use ``X_Access_Token`` in the header of your requests
please specify the ``AUTH_HEADER_NAME`` to be
``HTTP_X_ACCESS_TOKEN`` in your settings.

Callable to determine if the user is permitted to authenticate. This
rule is applied after a valid token is processed. The user object is
passed to the callable as an argument. The default rule is to check that
the `is_active` flag is still `True`. The callable must return a
boolean, `True` if authorized, `False` otherwise resulting in a 401
status code.
``USER_ID_FIELD``
-----------------

`AUTH_TOKEN_CLASSES`
====================
The database field from the user model that will be included in generated
tokens to identify users. It is recommended that the value of this setting
specifies a field that does not normally change once its initial value is
chosen. For example, specifying a "username" or "email" field would be a poor
choice since an account's username or email might change depending on how
account management in a given service is designed. This could allow a new
account to be created with an old username while an existing token is still
valid which uses that username as a user identifier.

A list of dot paths to classes that specify the types of token that are
allowed to prove authentication. More about this in the `Token types`
section below.
``USER_ID_CLAIM``
-----------------

`TOKEN_TYPE_CLAIM`
==================
The claim in generated tokens which will be used to store user identifiers.
For example, a setting value of ``'user_id'`` would mean generated tokens
include a "user_id" claim that contains the user's identifier.

The claim name that is used to store a token's type. More about this in
the `Token types` section below.
``USER_AUTHENTICATION_RULE``
----------------------------

`JTI_CLAIM`
===========
Callable to determine if the user is permitted to authenticate. This rule
is applied after a valid token is processed. The user object is passed
to the callable as an argument. The default rule is to check that the ``is_active``
flag is still ``True``. The callable must return a boolean, ``True`` if authorized,
``False`` otherwise resulting in a 401 status code.

The claim name that is used to store a token's unique identifier. This
identifier is used to identify revoked tokens in the blacklist app. It
may be necessary in some cases to use another claim besides the default
`jti` claim to store such a value.
``AUTH_TOKEN_CLASSES``
----------------------

`TOKEN_USER_CLASS`
==================
A list of dot paths to classes that specify the types of token that are allowed
to prove authentication. More about this in the "Token types" section below.

A stateless user object which is backed by a validated token. Used only
for the experimental JWTTokenUserAuthentication authentication backend.
The value is a dotted path to your subclass of
`rest_framework_simplejwt.models.TokenUser`, which also is the default.
``TOKEN_TYPE_CLAIM``
--------------------

`SLIDING_TOKEN_LIFETIME`
========================
The claim name that is used to store a token's type. More about this in the
"Token types" section below.

``JTI_CLAIM``
-------------

The claim name that is used to store a token's unique identifier. This
identifier is used to identify revoked tokens in the blacklist app. It may be
necessary in some cases to use another claim besides the default "jti" claim to
store such a value.

``TOKEN_USER_CLASS``
--------------------

A stateless user object which is backed by a validated token. Used only for
the JWTStatelessUserAuthentication authentication backend. The value
is a dotted path to your subclass of ``rest_framework_simplejwt.models.TokenUser``,
which also is the default.

``SLIDING_TOKEN_LIFETIME``
--------------------------

A ``datetime.timedelta`` object which specifies how long sliding tokens are
valid to prove authentication. This ``timedelta`` value is added to the
current UTC time during token generation to obtain the token's default "exp"
claim value. More about this in the "Sliding tokens" section below.

A `datetime.timedelta` object which specifies how long sliding tokens
are valid to prove authentication. This `timedelta` value is added to
the current UTC time during token generation to obtain the token's
default `exp` claim value. More about this in the `Sliding tokens`
section below.
``SLIDING_TOKEN_REFRESH_LIFETIME``
----------------------------------

`SLIDING_TOKEN_REFRESH_LIFETIME`
================================
A ``datetime.timedelta`` object which specifies how long sliding tokens are
valid to be refreshed. This ``timedelta`` value is added to the current UTC
time during token generation to obtain the token's default "exp" claim value.
More about this in the "Sliding tokens" section below.

A `datetime.timedelta` object which specifies how long sliding tokens
are valid to be refreshed. This `timedelta` value is added to the
current UTC time during token generation to obtain the token's default
`exp` claim value. More about this in the `Sliding tokens` section
below.
``SLIDING_TOKEN_REFRESH_EXP_CLAIM``
-----------------------------------

`SLIDING_TOKEN_REFRESH_EXP_CLAIM`
=================================
The claim name that is used to store the expiration time of a sliding token's
refresh period. More about this in the "Sliding tokens" section below.

The claim name that is used to store the expiration time of a sliding
token's refresh period. More about this in the `Sliding tokens`
section below.
Loading

0 comments on commit a96c525

Please sign in to comment.