In JWTAuthentication.get_user, the user is retrieved using the objects manager directly, without providing an easy way to customize the queryset:
|
try: |
|
user = self.user_model.objects.get(**{api_settings.USER_ID_FIELD: user_id}) |
|
except self.user_model.DoesNotExist as e: |
|
raise AuthenticationFailed( |
|
_("User not found"), code="user_not_found" |
|
) from e |
Currently, the only way for users to modify the queryset is by overriding the entire method—something that's discouraged due to maintainability and future compatibility concerns.
Introducing a get_queryset method would allow developers to tailor the queryset for different scenarios (e.g. annotating users who hold a valid license) for further checks and validations, without performing extra database queries.
This pattern aligns with how Django REST Framework typically works—it relies on get_ methods (like get_queryset) that return default values unless explicitly overridden:
https://github.com/encode/django-rest-framework/blob/c41314f1fc898490f27e1015cc859e28afe6f7b9/rest_framework/generics.py#L52-L92
In
JWTAuthentication.get_user, the user is retrieved using the objects manager directly, without providing an easy way to customize the queryset:djangorestframework-simplejwt/rest_framework_simplejwt/authentication.py
Lines 131 to 136 in acb1483
Currently, the only way for users to modify the queryset is by overriding the entire method—something that's discouraged due to maintainability and future compatibility concerns.
Introducing a
get_querysetmethod would allow developers to tailor the queryset for different scenarios (e.g. annotating users who hold a valid license) for further checks and validations, without performing extra database queries.This pattern aligns with how Django REST Framework typically works—it relies on
get_methods (likeget_queryset) that return default values unless explicitly overridden:https://github.com/encode/django-rest-framework/blob/c41314f1fc898490f27e1015cc859e28afe6f7b9/rest_framework/generics.py#L52-L92