Future of django-rest-framework-jwt

[SPKorhonen]

Do you intend to actively maintain and develop this package?

I'm asking as I have projects which use this package and I have been maintaining a private version with additional bug fixes. If you intend to maintain this would you consider pull requests and do you intend to merge pull requests submitted to orginal repo (GetBlib)?

[jaycle]

This fork has seen way more activity than the original GetBlimp version. It would be great if the author and PyPi package holder of djangorestframework-jwt @jpadilla could comment on this. Competing solutions are fine but I think the Django community would benefit more if the competition wasn't from just forks of abandoned projects. Perhaps there's room for this fork to "replace" or take-over the djangorestframework-jwt version?

[mjun]

GetBlimp version was a dependency for several of our projects and since we upgraded to drf versions > 3.6 we saw potential incompatibility problems down the road and decided to create drop-in replacement fork so we can make sure everything will work as we upgrade.

To answer @SPKorhonen questions: Do we intend to actively maintain and develop this package? Yes and no. We will upgrade this package to be 100% compatible with up to the most recent versions of django and drf and we will probably backport functionalities from django-rest-framework-simplejwt (token blacklisting) but we will probably not add new features at this time (to be honest I don't even know what additional features would that be :smiley: ).

Regarding pull request from original GetBlimp package - that is a possibility but not likely any time soon. If there is something in particular that interest you from GetBlimp pull request list let me know and I'll take a look - maybe we can squeeze that in :wink:

[jaycle]

Thanks @mjun for the explanation and reply. For me, the "feature" I came here hoping to see included is a fix for the CSRF vulnerability when using Jwt in the HttpOnly cookie. There's an open pull request to address this in the parent project.

[jayvdb]

I did a bit more testing of this, using it for builds of other packages which currently depend on the real django-rest-framework-jwt.

• django-rest-auth - limited testing indicates this is ok on Py 2/Django 1.11 - I've yet to get Py 3/Django 2.2 tests fully working
• drf-jwt-devices - fails due to missing rest_framework_jwt.compat.get_user_model (and probably others)
• drf-jwt-2fa - fails due to missing rest_framework_jwt.compat.Serializer
• django-rest-framework-jwt-refresh-token - fails due to missing rest_framework_jwt.utils.jwt_encode_handler (and maybe others)
• django-trench - fails due to missing rest_framework_jwt.utils.jwt_encode_handler (and maybe others)
• rest-social-auth - fails because jwt_decode_handler return value doesnt include element 'email' - I'll investigate this one further, as this one looks a bit more complicated than simply a broken API.

I would be happy to send a PR to re-add compat.py, and a few other bits of backwards compatibility, if there is a willingness from the maintainers to keep backwards compatibility where sensible, on a best-efforts basis, at least where it is needed to support PyPI published packages that work with django-rest-framework-jwt and have a credible test suite.

Or: this fork can break stuff, but will accept repair patches when there is another app which is fairly mature that is using a broken piece of the old API. And wont use 'they can change their code' as a reason to not accept repair patches here, as requiring new/future versions of other software is not helpful to people trying to keep old software running.

[jayvdb]

I should also clarify that the omission of the dependency on django-oauth-plus and django-oauth2-provider was a very important change made by this fork, and would be excluded from any backwards compatibility. They are dead, and unlikely to be revived.

However,

• django-oauth-plus has a maintained rewrite with the same import structure at django-oauth10a-mod, and
• django-oauth2-provider has several maintained forks, of which django-oauth2 and edx-django-oauth2-provider are the best.

I have run the django-rest-framework-jwt test suite with django-oauth-plus and django-oauth2-provider replaced with django-oauth10a-mod and django-oauth2/edx-django-oauth2-provider, and the tests all pass on Python 2/Django 1.11, but there is one failure on Python 3/Django 2.2 which I presume is unrelated to the quality of those replacements.

It would be possible to restore the previous functionality using new implementations, but again that would depend on if there is a real need for that part of the old django-rest-framework-jwt. I havent found any PyPI installable django app which does rely on it - probably most maintained apps have switched to django-oauth-toolkit or other alternatives.

[jayvdb]

Note that we do have a merge at https://github.com/Styria-Digital/django-rest-framework-jwt/pull/9 , so we have an active collaborative fork happening, folks :sparkles: ;-)

[jpadilla]

Thank you all for this conversation. I've just posted an update: https://github.com/GetBlimp/django-rest-framework-jwt/issues/484

[creyD]

First of all: Thanks for all the good work to everybody. Using this project regularly I came to wonder: what will happen here in the future? If I read it correctly @jpadilla offered to transfer all resources to this project.

I'm willing to transfer repo, pypi, etc, to keep this [django-rest-framework-jwt] going.

Is this encouraged? When setting up a new project most of the time I search for the project in google or GitHub and still land on the old repo, just to get the correct pypi name for this project here. It seems to me that it would be beneficial to merge both projects on GitHub and PyPi.