Maintenance

[shadow-light]

Thanks for all your work on this project @tikurahul. It is very useful and I haven't found any good alternatives for my use case.

Just wondering if you foresee having any more time to work on it in the near future? There doesn't seem to have been many commits for a couple of years now, and there are lots of remaining issues and some pull requests that haven't received attention. I'm sure you must be busy with other projects, so also wondering if you know who might be able to take over if so? Someone from OpenID?

(Since OAuth is all about security, I feel like it's more important than normal to have regular maintenance)

[tikurahul]

Hi 👋,

Thanks for the question.

The library's goal is to make OAuth2 and PKCE easy. We also do NOT want to support things that require users to enter credentials like (password based flows), and implicit flows.

What specific features / issues are you referring to ? There have been some feature requests to expand the scope of the library beyond what it does today. I don't think we need to make it a part of this library. The goal of the library is to be extendable to make it possible to support your use-cases but not necessarily implement them out of the box.

I do address any security issues reported, and given that the code base is mature there is a not a lot left to do.

Also, note this library is very widely used so it comes with a burden of responsibility that I am very aware of it.

[shadow-light]

Yes that sounds reasonable to me. I'm not very interested in additional features, just improving what is already there.

There's not many issues, it's just that they haven't been addressed for a couple of years already despite pull requests, which made me wonder if this package is still being maintained or not. And there hasn't been feedback on why the pull requests haven't been merged so that the authors can correct them.

I ran into these issues myself while using the package:

• Minor security issue with ip used: Notifier server should only bind to loopback interface #93
• Lack of documentation (aside from examples)
• Customising success message Allow modification of the message after successful authorization #85
• Disabling logging: Can logging be disabled? #75

Most significant has been that errors don't keep their stack traces, and the lack of reporting of error response body. I have an open PR for the later already: #183 . These things are very important for my use case when the errors are being reported from production usage, as you can't just pull up dev tools and inspect the network requests.

I've forked already to solve some of these for myself, but happy to contribute back if you're open to more PRs.

[shadow-light]

I also ran into this issue that was just closed #135

I see your point that that could be considered a feature, supporting resuming previous auth requests, and that's probably fine to not support. But that issue was also a defect in the current implementation and prevents the app from functioning at all because future requests get blocked. I implemented my own node-side logic instead to get around that, and so I could provide my own success response.