-
Notifications
You must be signed in to change notification settings - Fork 62
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
Comments
This fork has seen way more activity than the original GetBlimp version. It would be great if the author and PyPi package holder of |
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 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 😉 |
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. |
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.
I would be happy to send a PR to re-add 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. |
I should also clarify that the omission of the dependency on However,
I have run the 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 |
Note that we do have a merge at #9 , so we have an active collaborative fork happening, folks ✨ ;-) |
Thank you all for this conversation. I've just posted an update: jpadilla#484 |
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.
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. |
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)?
The text was updated successfully, but these errors were encountered: