This project is back under active development and maintenance!
thomseddon opened this issue · comments
Hello!
After a hiatus following the 3.0.0 release, I'm very happy to say that I will am planning to pick up the maintenance and development of this project. The point of this issue is to outline the plan.
History
3.0.0 was released in August 2017, when the project was already 4 years old, and was the result of a great amount of effort from a number of people in iterating towards a much improved codebase and documentation. Unfortunately, following this all of us who were involved in the release became rather busy with projects elsewhere and were not able to continue to work on the project. As such, we've been stuck on 3.0.0 since then!
I put out a request for maintainers in 2019, although I did receive a few responses I didn't find anyone who was able to start in earnest.
The action that drew most traction was a complete rewrite of the project in typescript in #564 - this was great to see, as was the amount of attention it got which showed there were still a good number of people using or interested in the project.
However, after observation of the progress of that project it's clear that the maintenance is still one of the hardest parts of such a project and I can understand why anyone would struggle to take that on. I realised that another big rewrite really wasn't what the project needed.
A change in my working situation has left me with a little more time to spare, I've been mostly using this on another OS project of mine (https://github.com/thomseddon/traefik-forward-auth) but I'd like to try and pick up this project too.
Plan
In summary:
- v3 - backwards compatible bug fixes only
- v4 - largely backwards compatible fixes and improvements (no code/model changes required)
A lot of people have been lingering on the 3.0.0 release for a long time and has certainly been battle tested. We've amassed over 100 issues and 22 PRs for this release so I would like to make a big effort to give v3 the fixes it deserves. I have already started this by updating all dependencies and releasing 3.0.2 🎉
In honour of the backwards compatibility, I will also be maintaining support for node 4/6/8 in v3.
Due to the nature of the project, most changes do change the server behaviour and so can be considered "backwards incompatible". To help prevent any jarring changes, the plan is for a v4 release which is as backwards compatible as possible. My goal is to keep the integration entirely backwards compatible, so there should be no client code changes required at all for this entire release. We will drop support for EOL node.js version 4/6/8 and plough through as many fixes and improvements as possible.
Thanks for your patience over the years, I'm already enjoying getting stuck back in again!
Will v4 based on v5?
No, it will be based on v3 and be mostly backwards compatible with existing code
Is it planned to implement those changes from v4 also in v5 or is v5 now dead?
So are you planning to "throw-away" all of the efforts that went into v5? Isn't Typescript meanwhile the de-facto standard for writing larger JavaScript-based projects?
All code has bugs - with v3 we have a somewhat battle hardened release with over 100 issues/PRs raised in this repo outlining many real bugs, doc issues and proposed features.
Whereas v5 is a massive rewrite with significantly less review in comparison - it may address some existing bugs, but will undoubtedly introduce new bugs.
As mentioned above, In the interest of forward momentum I'd like to fix the bugs and make the project better 👍
Thanks a lot for going this path. It's great to see, that I can continue to rely on this package. Is there a way to send a small donation 💰 to show some ❤️
We are with you. Thank you so much for the support and the awesome work you are doing?
Is v5-dev branch really dead ? As i understand, typescript version is not any more in the roadmap.
It's true, it's important to be backward compatible, but it's also important to move forward and update the code to support latest features of oauth2.
Some of thoses features were implemented in v5-dev and we were waiting for those to be merged. Better typing,
Pkce was also one of them. Can we expect to get it soon ?
You talk about v4, but we didn't see any branch related to it. Is this really planned ?
We know it's important to get help.
How can we help you to move forward ?
We just won't want to write code that is going to be "throw-away" like in v5-dev.
I think it would be great to have a v4 branch and a v4 project that contains all the issues relevant for v4. By doing so we know where to put our efforts in.
@thomseddon what do you think?
👍 3.1 will be released next week (3.1.0-rc1 is published on npm now)
The existing next branch was actually pegged for v4 and includes some necessary breaking changes. I'll create a new v4 branch shortly which will be based on the existing next branch, rebased from master/v3-catchup (#629)
I'm hoping to merge the existing PKCE PR into v4 too.
For those that have asked about sponsorship - thank you so much, I'd really like to spend more time on this project (there's a lot of work to do :) and I've setup github sponsorship, so for anyone who would like to help in that way it would really allow me to focus more time into this and would be greatly appreciated.
Hi! Any news on PKCE implementation?
This Project is imho again dead.
I think there should be someone getting sponsored to tackle the remaining issued or at least to manage incoming PRs.
@thomseddon honestly i'd say put v3 into maintenance mode (security fixes only), skip v4, and start pushing forward on v5 /w typescript and breaking changes. it's daunting work to build out improvements for 3 separate versions. if you don't have much time then reducing the surface area will surely help, and the typescript branch seems much cleaner to work with and build upon.
Is there a branch already for v4?
I agree with @night that managing 3 versions is a huge effort and maybe also the reason this repo getting stuck again?
@ukneeq I think it's the dev branch
I dont think, that the complexity is the reason that this project got stuck again. I suppose when @thomseddon was claiming that this project is under active development and maintenance, that he was in a jobless situation and thats why it was back under development... But soon after he was again busy with a job which supplies him with money. And so this Project is stuck again. I mean it is totally understandable, I would also be less productive in an open source project, if I have a paid Job.
What you gonna do? Issue is also, that this is a security relevant product. If you have a not trustworthy contributor/maintainer which puts malicious code into the product, then alot of companies will be hackable. But on the other hand, we can have a critical community and make it necessary to have x approvals before the maintainers can actually merge into master. I would also agree that new maintainers need to disclose their identities and who their employers are, so that making them to be maintainers does not mean to make a malicious anonymous able to taint the code.
I would be happy if I could support this Project.
I Support the Idea
If you are still in need of maintainers let me know, I really enjoy using this module and would be happy to contribute and improve it as much as I can!
Maybe we should Talk with another group Like auth0 and ask if they fork it and maintain it with our community support.
>This project is back under active development and maintenance!
Sooo that was a lie.
Would be great to have at least some kind of election for maintainers so this can continue to stay alive.
I think there would be a lot of people willing to maintain this project. The only thing that is missing are specifics tasks or todos that people can assign to themselves.
Personally I think the typescript version (v5) should be picked up again.
If we could define some reliable criteria for someone becoming a trusted maintainer we could start elections and @thomseddon only needs to add them. I think from there we could work in fixes for 3.x and 5.0 as well
The trusted maintainers can assign taks, review and merge PRs
I think the minimal effort should be to at least merge in updated dependencies e.g.: #677 and similar
I wrote this today to auth0:
Hello Auth0 Dev Team,
I wanted to ask you if your developers could fork the node-oauth2-server project on github.
https://github.com/oauthjs/node-oauth2-server
Alot of products use this project but the maintainer of the project abandoned it. We, the community, provided various PRs for this product, but till today the maintainer does not merge anything. We discussed about forking off the project, but tbh. this product is too security sensitive to have it maintained by the community in a noname github repo.
I personally would prefer if auth0 would be the trustworthy maintainer of the product. So you would fork the project and continue it as e.g. auth0/node-oauth2-server. We, the community, could then provide PRs and could have atleast some progress.
I hope you join us in the discussion on github:
Thank you very much!!!
Best Regards
Aras Abbasi
I wrote an identical E-Mail to the CEO of auth0.
Lets hope this project gets finally the love it needs. :)
Hi Aras,
Thank you for thinking of Auth0 when considering trustworthy open source maintainers.
From a quick glance, the main project’s aim appears to be implementing an OAuth2’s authorization server in Node, so that developers can host that function themselves in their codebase.
While that is an approach that has its rightful place in a number of scenarios, we believe that in the more general cases developers are better served by offloading authentication to a service- where they can rely on experts and cloud infrastructure to bear the brunt of the security, availability, manageability, scalability, compliance, interop and change management that are typically very onerous and tricky to achieve in one’s own code, unless identity and security are the core business of the implementer. You can find a summary of our thoughts on the matter here.
As such, I am sure you can see how it would be hard for us to pick on the mantle of maintainer for this project. I do hope you’ll find a viable maintainer, and I look forward to help in case you’ll want to test interoperability with our services!
Best,
Vittorio
So... any other idea how to get this project under "control"?
As I said 1 year ago, We started implementing our own version of an oauth2 server with typescript.
It's a draft at the moment and does not cover the entire project. However if you want to have a look, you're welcome.
It is build to work with Express and Fastify and we are ok to open the project to maintainers.
https://github.com/Pop-Code/oauth2
It is build to work with Express and Fastify
We are using sencha/connect so for us this would already be a nogo to add another library just for compatibility reasons.
So... any other idea how to get this project under "control"?
@Uzlopak Under "control" would only mean to either hard-fork, use a new project (as proposed by @Rmannn ) or get @thomseddon or @nunofgs to add a few people as new core contributors. I personally prefer the last one, however this might be the least realistic option at the moment.
Hi Aras,
....
So... any other idea how to get this project under "control"?
Sad but I understand why Auth0 wants us to use their software and not let us (non experts lol) make our own implementation. It is a business after all and they don't wanna be held responsible for anything that might go wrong.
Is there a way to contact @thomseddon other than Github? Maybe a twitter or e-mail so we can get him over here? He doesn't seem that active on Github so he could just be outright not knowing or ignoring this.
We just ask that he gives ownership to someone else who will be dedicated to the project. It's not that hard! Please!
I can also understand this. But on the other hand, we want oauth2 and not openid-connect.
Who wants to contact Thom?
Who wants to contact Thom?
Maybe we should try Twitter first, but I don't have one. Facebook might be too personal lol. I wouldn't be opposed to LinkedIn either, thought that would require to connect with him too. I'll see who'll pull the trigger first before I ask him 🤣
Sent the tweet: https://twitter.com/Kuester_Jan/status/1381520364275179524
By the way - is @thomseddon really the only one with respective permissions regarding this issue? What about
taken from https://github.com/orgs/oauthjs/people
I think this is Just a lose group.
Well no feedback. Should we now contact his work email?
@Uzlopak that would be hard on the one side but maybe they know what's going on, since there is even no activity on GitHub at all from him since Feb'21
Hey guys, so any response from anyone? If not I will e-mail their work e-mail first thing tomorrow morning.
Hi Everyone. I was hoping @thomseddon could chime on his intentions and future plans for this project, as ultimately its his project and I'd like to respect his will.
In the interest of keeping this package active and maintained, given a few months have passed without any feedback from Thom, I think it's time for me to add new maintainers to ensure this project remains alive. The risk of having no security fixes has to be balanced with the risk of adding new contributors.
@jankapunkt @HappyZombies @Uzlopak have you discussed short-term and long-terms plans for the project already? Triaging tickets, fixing bugs on existing versions, PCKE support, typescript support and others?
Hey @ruimarinho thanks for getting in on this thread!
We haven't discussed anything extensive, mainly because well....we've been waiting around for a response from someone. But definitely first order of business would definitely be updating dependencies (and of course assuring unit tests pass). Next, since this package hasn't been updated in almost a year, I think it then would be appropriate to address any bugs/triage issues people are having.
After that we should definitely start working on PCKE support (or verifying that the PR that's present is valid), especially since npm audit is throwing a high severity for this module. See Issue #688 and PR: #658
So to recap:
First Order of Business Plans:
- Update dependencies, assuring tests still pass.
- Address any bugs found; review triage issues made, along with reviewing any PRs.
Short Term Plans:
- Fix any major bugs found during triage and/or address breaking changes from dependencies.
- PKCE Support
Long Term Plans:
- TypeScript Support
@jankapunkt @Uzlopak please feel free to pitch in any other ideas that you guys have. I'm ready to get started whenever!
I'm happy to help with reviewing, Integration- testing builds against our workflow Implementations, GitHub actions and improving documentation, where needed.
The problem now is that I am actually an organization member and not owner, so while I can publish npm packages, I can't add new folks to this repository. @mjsalinger are you able to help here?
Hi everyone - I know a few of you have contacted me along with other owners/maintainers regarding getting this project moving again. Although I've moved on from my last position and don't use this project in my day-to-day anymore, I think it's a great project and would like to see it continue/move on.
I'm not comfortable yet with adding new people to the org, as this is really @thomseddon's baby. If he gives the go-ahead, I'll start to add maintainers. What I can do in the meantime is start to maintain this for a few hours a week, accept PRs from others, review, etc, and get close to a release... I'm a big fan of small, incremental releases that don't break compatibility as much as possible, so rather than try to plan a big v4.0, it may make sense to pick a handful of PRs that we all think are really important, and get the 4.0 out and start iterating from there.
I also think at this point it makes sense to drop support for v2, and only backport critical fixes into v3 if those come up.
I need a week or so to go through the project and start to look at where things at, and start to review the PRs. In the meantime, what do people think are the most important things to be included in a v4?
Let me know what you think of the plan - it may take a few weeks to get going, but I hope we can revive this repo and build a community of maintainers over time. I want to give Thom a chance to chime in, but I'll look to add maintainers in a month or so if we don't hear from him...
Hope we can get this back on track, and then expand the pool of maintainers to help keep this library moving forward.
@mjsalinger Thank you so much for reaching out to us and helping out! We've been trying to contact @thomseddon for awhile now so hopefully we can hear back from him soon. Like I've said I would be happy to be on of the maintainers since I really, well, believe in it and want to see it continue as well! But we will see what he says/happens.
In the meantime, I am 100% on board with the plan of just slowly rolling out a v4 with small releases that don't break anything; this can include any bugs fixes that are on the issue board along with reviewing PRs (updating dependencies, reviewing bug fixes, etc.). I will look over the issue board and PR board to see what I think can/should be included in v4 and make another comment today or in the following days. 👍
I think we can also possibly squeeze in PKCE at the least for version 4, but we will see.
Looks like @thomseddon is alive (librenms/librenms#12898) so either just is ignoring these mentions or isn't getting them.
I'm potentially looking to use this package in the near future. Either it will be via a fork that is purely for private use or via this if some maintainers pick it up again. I note that @mjsalinger has offered to put some time into maintaining the repo and taking in contributions which is great.
I'd make two points:
- Any new maintainers need to be vetted somehow, I don't think it's going to be OK just to take random people who are "interested" in the project on board as maintainers, that kind of decision should be taken cautiously and those that are chosen should have a track-record of maintaining decent sized libraries
- If this project does start to see active development again and other maintainers are added, if @thomseddon doesn't come forward with some formal sanctioning of it, I'd be worried that in the future he could come along and revoke those permissions.
In conclusion I'd suggest a proper vetting process for any new maintainers that come forward (or better, that are chosen) and @thomseddon (and any others no longer interested in maintaining the project) being removed from it.
Hi everyone,
So I've spent some time looking at the codebase - and I wanted to propose how I think we should proceed. A few years ago when I was working on this project more actively, I set up dev, 2.x and 3.x brnaches. They've since fallen out of sync, and a 4.0.0-dev.2 has been released (but the commits for that are not in any branch as far as I can see). I think starting to manage all of these different branches may be too complicated, so here is what I propose:
- 2.x is now deprecated and will have no further releases
- The 3.x branch will be preserved (and brought up to date) but also deprecated, no furhter changes will be made to this branch.
master(will be renamed tomain) will get the 3.x latest changes as that is the last stable release for now. - The
devbranch will get the 4.x changes for now and we'll work off there until we get a stable release. Once we're ready for a 4.0 final, that branch will be merged directly intomain. (No 4.x branch).
I'm ready to start reviewing/testing/merging and hope to get a -dev.3 release out with at least some minor fixes by end of the week. And I would also like to get PKCE into the 4.0 dev branch but I think that may go into next week (dev.4). I will need some people to volunteer to help test the dev build, as I no longer have an active project that uses this library, and it will take me a little time to throw something together that I can use to do manual testing.
Appreciate everyone willing to volunteer, as I said I'm happy to take this on, but will need support from this community and help where needed to make it successful. Let's do this!
Thanks for investing the time to get this project going again, @mjsalinger! I'm happy to test any pre-release versions with our application.
I will need some people to volunteer to help test the dev build
We use this package for implementing an authorization code grant workflow and we are also happy to run our integration tests against any upcoming releases.
I will need some people to volunteer to help test the dev build
100% on board to help, I use this module extensibly and even have custom grant type and custom extensions...so I do a lot with this lol, I am sure I can hit a lot of corner cases too. Super excited, thanks A LOT @mjsalinger for getting this project rolling.
I am currently very occupied. But I think I can help to review the PRs.
Tbh we should start with updating lodash to atleast kill one of the npm audit issues.
@mayrbenjamin92 fyi
Yep - happy to help test. My workflow is mainly client_credentials grant and bespoke grants. So, like @HappyZombies, should be able to test some of the less standard areas.
Hey all - just a brief update. It's taken me a little longer than planned to work this out, mainly because the branch structure of this repo is a bit of a mess at the moment with various commits in various places. The 4.x releases so far, for example, didn't have all the commits from the 3.x branch, so I need to sort this out a bit. I'm making progress but it will probably take a few more days to sort this out and get that first dev release out. Sorry for the delay.
All good @mjsalinger! We understand, hopefully after the cleanup of the branches and the commits the project will be cleaned up, I mean it hasn't been updated in nearly a year so we'd understand what needs to happen. Appreciate the update and the work you're putting in! Can't wait for the next update :)
Hi everyone,
So sorry for the radio silence and that you felt the need to track me down, we're going through a very consuming investment process at work and between that and a young family, I definitely don't have any time to spare for this project unfortunately.
Thrilled to see @mjsalinger able to pick this up for a while. Adding new maintainers would be brilliant, as previously said my preferred methods for doing this is for anyone wanting to become a maintainer to begin by triaging issues and submitting PRs as-is, once input has been shown to be rational and useful we can provide "triage" permission and then once a level of trust has been established then we can progress to "write" access. Welcome to any other ideas on how best to handle this, but I think everyone would agree we need to be careful in how we expand members.
FYI @mjsalinger my singular recent act was to curate and release #629 which rolled up everything in the 3.x branch (excluding a few commits as noted in the PR) and was released as 3.1. Those changes will need to be preserved in the v4 release too.
Published 4.0.0-dev.3 which mainly contains dependency bumps under the dev tag on npm. Now that I have this going, expect a regular cadence of dev releases over the next several weeks - let me know if you encounter any issues. I'll continue to announce dev releases here for the time being, with the hopes of a beta by end of June/early July. Let me know what you'd like to see in this release and I'll try to get those in. PKCE seems to be a big one that I'll shoot to review next.
Changelog
- Bump jshint from 2.12.0 to 2.13.0
- Bump jshint from 2.12.0 to 2.13.0
- Upgrade to GitHub-native Dependabot
- [Security] Bump lodash from 4.17.19 to 4.17.21
@mjsalinger what about those who are using v3? It would be really helpful to bump dependencies for that generation. lodash is also vulnerable there!
The 3.x branch will be preserved (and brought up to date) but also deprecated, no furhter changes will be made to this branch. master (will be renamed to main) will get the 3.x latest changes as that is the last stable release for now.
@mjsalinger how are things going? Need assistance with anything? Currently using 4.0.0-dev.3 and it's working good so far! Appreciate the dependency updates 👏
Can confirm the same with our authorization code workflow and 4.0.0-dev.3 - everything runs fine, no issues since we installed it.
Update: Currently reviewing and testing the PKCE code - want to put that through its paces a bit, should have it merged and a dev release tagged early-mid next week sometime, possibly along with a few other smaller PRs...
Would it be possible to remove the following dependencies?
- bluebird -> Native Node Promise
- promisify-any -> utilis.promisify
- statuses -> http.STATUS_CODES
@jwerre - I think you should probably open issue(s) for those things and even consider authoring the PR.
Actually Changes sound interesting. Maybe the Bluebird replacement should be done in the way that we kind of dependency inject it. Fallback is native Promise implementation. If there is somebody for any reason depending on bluebird or thinks it is faster, he can just override it with Bluebird?
@Uzlopak mongoose does something like that, not a bad idea. I'm not sure why you'd need to do that though, Promises have been available since version 0.12.0. There's really no need to shim Promise anymore.
Exactly. I thought about mongoose. back in those days performance of native promises was slower than bluebird. But tbh we are now at node 14/16. The performance bottleneck does not exist anymore.
I just think we should consider this.
I personally prefer to use native Promises, without the injection technique I mentioned.
@mjsalinger I'd be happy and go through the code and make these changes. That said, I understand the security implications.
Please make them separate. One for promise, one for utils.promisify and one for the statuses. I would review then
Status update?
We just need one new, serious maintainers; there's clearly there's no communication or time from the current maintainers, and I also feel like there's no time to "build a level of trust" when the maintainers themselves aren't even active here.
Everyone, I went ahead and just forked on this project and will work on it, hop on hover and let's talk about the future of the project over there.
The project is now under a new organization for easier development.
I will join, however I still would love to see this project getting things done or finally making people maintainers that actually have the time and commitment to improve things. I think there were numerous mentions in this thread who would participate etc.
cc @Uzlopak @jwerre @dhensby @Milad @jorenvandeweyer @ukneeq @night @gabriprat @mayrbenjamin92 @desaijay315 @Rmannn please also think about what you would invest to keep this alive, maybe under a new organization, we would be enough people to cover most aspects of the development process for maintenance and maybe even continue to improve.
We can use the fork of @HappyZombies in the meantime to discuss things further and don't further pollute this thread
@jankapunkt good idea about making this an organization and just adding people, I'll carry the conversation over there.
I see many of you reacting confused and I'd like to know why. I know it's hard to just jump from a 3.4k stars project with established level of trust to something empty but I for example can't wait for all the vulnerabilities to be closed in 2022 because we have an audit soon. I don't know your situation but I prefer to keep such a critical tool updated as possible.
Hey - from my side, I'm actually happy to see the fork! As mentioned before, I've always had a security concern with promoting a maintainer without at least establishing a base line level of trust and competence. I've suggested to those who are willing to begin triaging but I can certainly see how a clean fork is easier.
If the fork goes in the right direction I'm happy to provide maintainer access for it to be merged in or replaced as is seen fit.
Can anybody suggest a good and "non vulnerable" fork? I am happy to start dedicating some of my spare time to support this project - we are heavily relying on it and having the vulnerabilities is a mess :/
Can anybody suggest a good and "non vulnerable" fork? I am happy to start dedicating some of my spare time to support this project - we are heavily relying on it and having the vulnerabilities is a mess :/
This is an active fork with the issues fixed.