Djangorestframework-simplejwt: error dict key `detail`

[rodrigondec]

Resume

Every response error related to django-rest-framework-simplejwt returns a dict in the following format:

{
    'detail': 'some error',
    'code': some_http_code
} 

Why use hardcoded detail key?

The DRF framework has the default NON_FIELD_ERROR_KEY which can be configured by the user.

https://github.com/encode/django-rest-framework/blob/3d708ac7005e29ca75aa68b447edb8d9dc111637/rest_framework/settings.py#L86

My front-end now has to handle non_field_errors and detail keys to look for errors!

If it was used the settings from DRF this wouldn't be hardcoded!

Use example

from rest_framework.settings import api_settings

data = {api_settings.NON_FIELD_ERRORS_KEY: str(exc)}

Refs

I linked every reference to detail hardecoded on the lib as of now.

https://github.com/SimpleJWT/django-rest-framework-simplejwt/blob/0fc7d52ad6401e445c32ad4dd84ef726553ba933/rest_framework_simplejwt/exceptions.py#L19

https://github.com/SimpleJWT/django-rest-framework-simplejwt/blob/0fc7d52ad6401e445c32ad4dd84ef726553ba933/rest_framework_simplejwt/exceptions.py#L38

https://github.com/SimpleJWT/django-rest-framework-simplejwt/blob/7c1d303e46e778351c1737027df258ee869e2e71/tests/test_integration.py#L27

https://github.com/SimpleJWT/django-rest-framework-simplejwt/blob/04a4f7f2e045ac4a49542b7e98350e66431adcf5/rest_framework_simplejwt/authentication.py#L96

https://github.com/SimpleJWT/django-rest-framework-simplejwt/blob/5c6a60b883fa9a8ad44dc11f0c6e836b2dc445d8/tests/test_authentication.py#L91

[Andrew-Chen-Wang]

Perhaps getting rest_framework settings and getting the non_field_errors in place of detail will work. PR welcome! make sure the settings.py in the tests folder sets the non_field_errors as "default." My only concern is that this will be a breaking change in the few repositories that externally test SimpleJWT, but it shouldn't be too big of a breaking change.

[Alig1493]

@Andrew-Chen-Wang could you elaborate on the part where you mentioned to make changes in the settings.py of the test folder?
I tried to make some changes for a PR but exceptions caught by the InvalidToken are producing outputs like this:

{'non_field_errors': 'Token is invalid or expired', 'code': 'token_not_valid', 'detail': 'Given token not valid for any token type', 'messages': [{'token_class': 'AccessToken', 'token_type': 'access', 'message': 'Token is invalid or expired'}]}

[Andrew-Chen-Wang]

@Alig1493 Changing the settings in the test folder specified by rodrigondec as seen by his link to a random value ensures that whatever your PR is trying to accomplish actually works. Simply using the defaults wouldn't be testing if a dev deliberately changed the setting for their environment.

My front-end now has to handle non_field_errors and detail keys to look for errors!

This is what you're trying to fix, so having some random value in place can weed out any problems. Hope that makes sense and thanks for working on a PR!

[Alig1493]

so is it safe to say the the error response output will contain both the details key (which is present in almost all of the APIException classes by the DRF ) ad well as the default NON_FIELD_ERRORS_KEY set in the project?

[Andrew-Chen-Wang]

Uh not quite. The problem right now is that if you get an error response, you'll get something like this:

{'detail': ErrorDetail(string='Authentication credentials were not provided.', code='not_authenticated')}

The problem at hand is that "detail" is hard coded. The point of the PR is to utilize non_field_errors_key.

Although your point about "which is present in almost all of the APIException classes by the DRF" is true I think. That's what made we wonder the first time around reading this why this change is necessary. Do you mind looking for some examples of "detail" being returned instead of non-field-errors? I'm just not sure if the change here is truly necessary.

[rodrigondec]

DRF uses the 'detail' keyword for API errors and DEFAULT_NON_FIELDERRORS_KEY for ValidationErorrs on the serializers (ONLY).

DRF Exceptions guide

rest_framework.views.exception_handler.py

All errors from serialization return a dict with 'field': 'detail value' or 'api_settings.DEFAULT_NON_FIELD_ERRORS_KEY': 'detail value'

'api_settings.DEFAULT_NON_FIELD_ERRORS_KEY' is not used in any file except the serializers files!

Refs

• https://github.com/encode/django-rest-framework/blob/82c2b5c3e75debe047eebd8a17b50c1e17594663/docs/api-guide/exceptions.md
• https://github.com/encode/django-rest-framework/blob/335054a5d36b352a58286b303b608b6bf48152f8/rest_framework/exceptions.py
• https://github.com/encode/django-rest-framework/blob/3f19e66d9f2569895af6e91455e5cf53b8ce5640/rest_framework/views.py#L96

My api return examples

[rodrigondec]

Although your point about "which is present in almost all of the APIException classes by the DRF" is true I think. That's what made we wonder the first time around reading this why this change is necessary. Do you mind looking for some examples of "detail" being returned instead of non-field-errors? I'm just not sure if the change here is truly necessary.

@Andrew-Chen-Wang With this in mind I agree with you. The lib is actually 'drf compliant'.

My fault for not understanding the use of 'detail' in DRF. Sorry guys :sweat_smile:

[Andrew-Chen-Wang]

It's good. I'm gonna close this on a note that the serializers employed here don't use non_default_errors like regular serializers since we're not serializing anything which can result in that kind of error. When validating the token, it's more of an authentication process hence why, at least for me, it should remain as "detail."