Closed jayvdb closed 3 years ago
Note this was found using https://pypi.org/project/schemathesis/ , which tries to find 500s like this. The correct response is either to blame the client (not 500 - the server), or ignore it so some other part of django could respond to it if they understand it.
@jayvdb Thanks for reporting this. If I understood the issue you've described in the listed issues, these tokens are malformed to begin with, so returning a 4xx response to the client sounds like the best way forward. Any thoughts on the matter?
For my own needs / use case, returning a 4xx response would be perfect.
However, should drf-jwt claim ownership of the auth? Or defer to other auth providers in case they can make sense of it ?
Sort of touched on that conundrum at
https://github.com/Styria-Digital/django-rest-framework-jwt/pull/71/files#r463141406
Considering the amount of possible authentication mechanisms per-site, I'm in favor of deferring.
A DEBUG
/INFO
level logger could be added if necessary, but then again, that implies that it could be troubleshooted locally using a debugger. I don't see the need for using a higher level logger as it would potentially clutter the logging service with noise which could only mislead developers.
The PR already defers.
This library doesnt do any logging. It would be odd to introduce logging only for this obscure problem.
Could you please review my PR. It is a bit annoying that there was a release without my PR. I need to use a git+ pip install in production because of this.
Python 3.6 and Django 2.2 , if there is some strange authentication header like
Bearer \x9d