This PR consists of two patches:

• The first adds support for accepting multiple keys
• The second adds support for named keys (with key ids)

Please refer to the individual commit messages and the updated documentation.

A changelog will be added to the PR if/when otherwise accepted.

Django 4.0 dropped today which removed django.conf.urls.url(). It looks like we're getting an import error here and subsequently here e.g.

ImportError: Could not import 'rest_framework_jwt.authentication.JSONWebTokenAuthentication' for API setting 'DEFAULT_AUTHENTICATION_CLASSES'. ImportError: cannot import name 'url' from 'django.urls' (/usr/local/lib/python3.8/dist-packages/django/urls/__init__.py).

I did a bit of searching through the codebase and it looks like we could switch to re_path or path for this project but I'm not 100% sure. Wanted to file an issue to get the ball rolling on a solution.

I needed a simple management command to use during development, in order to obtain JWT token for my test user easier, I thought it might be helpful to open a PR on the main repo.

We add settings analogous to SESSION_COOKIE_* for the JWT cookie:

'JWT_AUTH_COOKIE_DOMAIN': None
'JWT_AUTH_COOKIE_PATH': None
'JWT_AUTH_COOKIE_SECURE': True
'JWT_AUTH_COOKIE_SAMESITE': 'Lax'

with the following differences to django:

• The HttpOnly attribute remains hardcoded as True in order to avoid unintended access from client code with addition of the Domain attribute.

BREAKING CHANGES with this patch:

This changes the default Secure attribute from False (actually None as in not present in Set-Cookie) to True. Users wishing to use JWT cookies over http (as in no TLS) need to set JWT_AUTH_COOKIE_SECURE to False.

This change is intentional to follow common best common practice.

CHANGES:

Adds the default Samesite attribute Lax

https://github.com/Styria-Digital/django-rest-framework-jwt/blob/9d97eab9ad3df81e7418b20b6f2a9dea6e489a0b/src/rest_framework_jwt/views.py#L40

The call to self.get_serializer at line 40 in BaseJSONWebTokenAPIView causes the payload created by api_settings.JWT_RESPONSE_PAYLOAD_HANDLER to be run back through the JSONWebTokenSerializer, effectively eliminating anything added to the payload by a custom handler other than the fields in JSONWebTokenSerializer. For example, the custom payload handler, that I wrote and have been successfully using with the original GetBlimp package, uses "authentication_token", rather than "token" to return the token, and includes some additional pieces of data, but with the new view, the only thing returned by the response is "email".

Fix decode call for migration.

I don't care about verifying the token value here; if it got as far as the database, it's reasonable to expect it was valid when it was inserted.

This was my mistake in Styria-Digital/django-rest-framework-jwt#84, which was released in v1.18.0, where I didn't test the migration properly with real data.

Python 3.6 and Django 2.2 , if there is some strange authentication header like Bearer \x9d

Traceback (most recent call last):
  File "/usr/local/lib/python3.6/site-packages/rest_framework/views.py", line 493, in dispatch
    self.initial(request, *args, **kwargs)
  File "/usr/local/lib/python3.6/site-packages/rest_framework/views.py", line 410, in initial
    self.perform_authentication(request)
  File "/usr/local/lib/python3.6/site-packages/rest_framework/views.py", line 324, in perform_authentication
    request.user
  File "/usr/local/lib/python3.6/site-packages/rest_framework/request.py", line 220, in user
    self._authenticate()
  File "/usr/local/lib/python3.6/site-packages/rest_framework/request.py", line 373, in _authenticate
    user_auth_tuple = authenticator.authenticate(self)
  File "/usr/local/lib/python3.6/site-packages/rest_framework_jwt/authentication.py", line 66, in authenticate
    token = self.get_token_from_request(request)
  File "/usr/local/lib/python3.6/site-packages/rest_framework_jwt/authentication.py", line 91, in get_token_from_request
    authorization_header = force_str(get_authorization_header(request))
  File "/usr/local/lib/python3.6/site-packages/django/utils/encoding.py", line 69, in force_text
    raise DjangoUnicodeDecodeError(s, *e.args)
django.utils.encoding.DjangoUnicodeDecodeError: 'utf-8' codec can't decode byte 0x9d in position 7: invalid start byte. You passed in b'Bearer \x9d' (<class 'bytes'>)

We recently updated from Django 2 to Django 3 and are now seeing quite a few deprecation warnings regarding RemovedInDjango40Warning: django.utils.translation.ugettext() is deprecated in favor of django.utils.translation.gettext() coming from this package.

I believe this is caused by the try-catch block in compat.py being "reused" for multiple imports where the first line seems to fail in Django 3:

https://github.com/Styria-Digital/django-rest-framework-jwt/blob/master/src/rest_framework_jwt/compat.py#L12

It looks like url is not part of django.conf and therefore always raises ImportError:

https://docs.djangoproject.com/en/3.0/ref/urls/

I believe the following should fix the problem in compat.py, I'm just not completely sure if the middle block even makes sense or of it should be completely removed:

try:
    from django.urls import include
except ImportError:
    from django.conf.urls import include  # noqa: F401

try:
  from django.urls import url
except ImportError:
  from django.conf.urls import url

try:
    from django.utils.translation import gettext as gettext_lazy
except ImportError:
    from django.utils.translation import ugettext as gettext_lazy

Basically this PR introduces two fixes when JWT_GET_USER_SECRET_KEY method is overridden,

• If the payload contains a non-existent user, a validation error will be raised (same as when the method is not overridden). Previously, when this happened, an uncatched error from Django.
• The jwt_get_secret_key method will now use the JWT_PAYLOAD_GET_USERNAME_HANDLER configuration.

The migrations for the new blacklist app fail because TextField can't have a unique constraint in MySQL: https://docs.djangoproject.com/en/2.2/ref/databases/#textfield-limitations . It fails with:

BLOB/TEXT column 'token' used in key specification without a key length

For now we can downgrade to 0.14.0 as we don't need the blacklist functionality yet, but this is a blocker for upgrading until not only a new migration fixes the problem, but the existing migration changes to not blow up on MySQL.

Ciao, MR to fix upstream issue: https://github.com/jpadilla/django-rest-framework-jwt/issues/455 Also django-axes requires request in authenticate "RequestParameterRequired: AxesModelBackend requires calls to authenticate to pass request as an argument."

I use Axes as authentication backend, but when set AXES_FAILURE_LIMIT ==2 in first login attempt the obtain-jwt-token return 403, while it must return 400 and if I call obtain-jwt-token again, it must return 403. I do not have this problem with https://github.com/jpadilla/django-rest-framework-jwt !

What is the best practice for restrict sessions in django-rest-framework-jwt? I mean admin restrict active session that means for example if userA login in computerA then when userA login from computerB, jwt in computerA is no longer valid and must login again.

I included 'rest_framework_jwt.blacklist' in INSTALLED_APPS as mentioned in the official documentation. However, I am getting the following warning about auto-created primary key every time I run or migrate the DRF app:

blacklist.BlacklistedToken:` (models.W042) Auto-created primary key used when not defining a primary key type, by default 'django.db.models.AutoField'.
	HINT: Configure the DEFAULT_AUTO_FIELD setting or the BlacklistedTokenConfig.default_auto_field attribute to point to a subclass of AutoField, e.g. 'django.db.models.BigAutoField'

Simply removing the blacklist app from INSTALLED_APPS will no longer show this warning, but wanted to make sure to avoid any DB issues. How can I manually configure the primary key for the blacklist app?

I'm dealing with a problem that seems related with this library (full traceback at the end)

 File "/home/gsp/.local/lib/python3.8/site-packages/rest_framework_jwt/authentication.py", line 86, in authenticate
    if BlacklistedToken.is_blocked(token, payload):
  File "/home/gsp/.local/lib/python3.8/site-packages/rest_framework_jwt/blacklist/models.py", line 58, in is_blocked
    return BlacklistedToken.objects.filter(query).exists()

My project is web application that receives astronomical images and automatically triggers the reduction process and displays them in the browser. So the django views run synchronously with gunicorn as the server. There is also a websocket service that runs independently with daphne (async). Same container and django app though. The problem happens when the backend sends a notification via websockets that a new file has "arrived" into the system and the frontend (react) requests /gsp/api/files/ to get an updated list of files.

I was wondering if there are plans to support async requests in the near future.

Here is the full traceback.

ERROR [2021-11-03 12:43:53,125] log Internal Server Error: /gsp/api/files/
Traceback (most recent call last):
  File "/usr/local/lib/python3.8/site-packages/django/core/handlers/exception.py", line 47, in inner
    response = get_response(request)
  File "/usr/local/lib/python3.8/site-packages/django/core/handlers/base.py", line 181, in _get_response
    response = wrapped_callback(request, *callback_args, **callback_kwargs)
  File "/usr/local/lib/python3.8/site-packages/django/views/decorators/csrf.py", line 54, in wrapped_view
    return view_func(*args, **kwargs)
  File "/usr/local/lib/python3.8/site-packages/django/views/generic/base.py", line 70, in view
    return self.dispatch(request, *args, **kwargs)
  File "/usr/local/lib/python3.8/site-packages/rest_framework/views.py", line 509, in dispatch
    response = self.handle_exception(exc)
  File "/usr/local/lib/python3.8/site-packages/rest_framework/views.py", line 469, in handle_exception
    self.raise_uncaught_exception(exc)
  File "/usr/local/lib/python3.8/site-packages/rest_framework/views.py", line 480, in raise_uncaught_exception
    raise exc
  File "/usr/local/lib/python3.8/site-packages/rest_framework/views.py", line 497, in dispatch
    self.initial(request, *args, **kwargs)
  File "/usr/local/lib/python3.8/site-packages/rest_framework/views.py", line 414, in initial
    self.perform_authentication(request)
  File "/usr/local/lib/python3.8/site-packages/rest_framework/views.py", line 324, in perform_authentication
    request.user
  File "/usr/local/lib/python3.8/site-packages/rest_framework/request.py", line 227, in user
    self._authenticate()
  File "/usr/local/lib/python3.8/site-packages/rest_framework/request.py", line 380, in _authenticate
    user_auth_tuple = authenticator.authenticate(self)
  File "/home/gsp/.local/lib/python3.8/site-packages/rest_framework_jwt/authentication.py", line 86, in authenticate
    if BlacklistedToken.is_blocked(token, payload):
  File "/home/gsp/.local/lib/python3.8/site-packages/rest_framework_jwt/blacklist/models.py", line 58, in is_blocked
    return BlacklistedToken.objects.filter(query).exists()
  File "/usr/local/lib/python3.8/site-packages/django/db/models/query.py", line 808, in exists
    return self.query.has_results(using=self.db)
  File "/usr/local/lib/python3.8/site-packages/django/db/models/sql/query.py", line 552, in has_results
    return compiler.has_results()
  File "/usr/local/lib/python3.8/site-packages/django/db/models/sql/compiler.py", line 1145, in has_results
    return bool(self.execute_sql(SINGLE))
  File "/usr/local/lib/python3.8/site-packages/django/db/models/sql/compiler.py", line 1173, in execute_sql
    cursor = self.connection.cursor()
  File "/usr/local/lib/python3.8/site-packages/django/utils/asyncio.py", line 24, in inner
    raise SynchronousOnlyOperation(message)
django.core.exceptions.SynchronousOnlyOperation: You cannot call this from an async context - use a thread or sync_to_async.

Hello,

Thank you for the awesome token authentication plugin.

I need to implement the api where super user can become anyone and debug the issue. I found the documentation on the token impersonation, however, It doesn't explain much on how to setup the api. Could you please provide more details on the same preferably example?
https://styria-digital.github.io/django-rest-framework-jwt/#impersonation-token

Please let me know if you need anything else.

Thank you