Skip to content

Future of django-rest-framework-jwt #4

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
SPKorhonen opened this issue Dec 20, 2018 · 8 comments
Open

Future of django-rest-framework-jwt #4

SPKorhonen opened this issue Dec 20, 2018 · 8 comments

Comments

@SPKorhonen
Copy link

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
Copy link

jaycle commented Jan 27, 2019

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
Copy link

mjun commented Jan 27, 2019

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 😃 ).

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 😉

@jaycle
Copy link

jaycle commented Jan 28, 2019

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
Copy link

jayvdb commented Apr 19, 2019

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
Copy link

jayvdb commented Apr 20, 2019

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,

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
Copy link

jayvdb commented Apr 25, 2019

Note that we do have a merge at #9 , so we have an active collaborative fork happening, folks ✨ ;-)

@jpadilla
Copy link

jpadilla commented Jul 8, 2019

Thank you all for this conversation. I've just posted an update: jpadilla#484

@creyD
Copy link

creyD commented Nov 10, 2022

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants