Skip to content
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

Version 2.0 Roadmap #83

Open
AdamPflug opened this issue May 2, 2019 · 16 comments
Open

Version 2.0 Roadmap #83

AdamPflug opened this issue May 2, 2019 · 16 comments

Comments

@AdamPflug
Copy link
Owner

Just thought I'd provide some context on the things I hoping to accomplish for a version 2 of express-brute, which I'd like to get out for beta in June:

Major Changes

Minor Improvements

@AnandChowdhary
Copy link

@AdamPflug Do you have a rough timeline for this?

@AdamPflug
Copy link
Owner Author

@AnandChowdhary I ran into some unexpected delays because of offline stuff, but I'm actively working on this now and targeting a beta release next week.

@animir
Copy link

animir commented Jul 10, 2019

@AdamPflug Hi, you could use rate-limiter-flexible package as underlying core.

rate-limiter-flexible provides a lot of features. It also provides a middleware ExpressBruteFlexible similar to ExpressBrute with the same options built on top of atomic increments.

Thoughts?

@AdamPflug
Copy link
Owner Author

@animir I've been considering it, but I have a few reservations:

  1. rate-limiter-flexible doesn't have a pluggable backend architecture, so it requires updates to the core to add new store options (e.g. amazon dynamodb).
  2. rate-limiter-flexible doesn't work with sliding timeout windows and requires you to jump through some hoops with multiple gets/sets per request to do exponential backoffs.
  3. I've got a bit of a bad taste in my mouth from my previous interactions with you around this project. One the bright side it's clear you're dedicated to making your project the best that you can.

I haven't made a final decision either way yet though (but it does look like work on this may continue out another week).

@animir
Copy link

animir commented Jul 13, 2019

@AdamPflug

  1. yes, some work would be required on both packages. And it would be good for both. You can develop the second version from scratch without compatibility with v1.
  2. agree, this can be optimised, if you do it your way. on the other hand, it would require much more time to RE-develop everything. you should find that balance.
  3. you've got a bad taste in your mouth, because this library is your child and it is complicated to treat criticism with clear mind :-)
    There is still PR Add note about possible race conditions #80, which must be in Readme, I think. You should highlight vulnerabilities, so users aware of possible consequences.

@ErisDS
Copy link
Collaborator

ErisDS commented Apr 21, 2020

Hey @AdamPflug I've read this and #46 and I'm wondering if there's anything that can be done to support you in your efforts?

Would love to see even a minimal update with up-to-date dependencies and keen to pitch in if possible, because we depend on express-brute, not cos of the bounty :)

@AdamPflug
Copy link
Owner Author

Thanks for the offer of support @ErisDS, If you can help with updating dependencies and testing/validating those changes I'd be love to review and merge that kind pull request and I'd be grateful for the help.

To be totally transparent I rarely use Express on new projects these days, partially because our work has been trending towards static site generators and JAMstack stuff with client-side oauth flows, and partially because we've been using Koa instead, so I haven't integrated express-brute in a new project in a while, which means felt the pain the stale dependencies myself.

Frankly I think TryGhost/Ghost is responsible for almost half of express-brute's installs right now, so I'd love to hear more about what your priorities for an MVP for v2.0 might look like (supported backends, etc) and be open to adding you as collaborators/maintainers as well.

@ErisDS
Copy link
Collaborator

ErisDS commented Apr 22, 2020

Thanks for the super fast reply!

I'd love to get an initial patch/minor update out that just does some super basic dev dependency updates and to resolve the license (the file is MIT, the package.json says BSD).

After that my priorities for a major would be getting the security vulnerability fixed (although I am in agreement it is flagged overly harshly) and if you'd allow it, swapping underscore for lodash as express-brute is one of only 3 modules in our dep-tree using it now 🙂

In terms of backends, we use memory + knex atm, with a desire to at some point support redis (for which there is a more up-to-date fork here maintained by one of Ghost's main contributors).

I'd love to be allowed to maintain the repo directly if that's something you'd be comfortable with.

@AdamPflug
Copy link
Owner Author

@ErisDS Sounds good, I sent you an invite as a contributor.

Let's start with the dependency updates and underscore->lodash swap for the first push. Also good catch on the license issue. I think my intention was to use MIT instead of BSD since my understanding was it's the less restrictive of the two.

@ErisDS
Copy link
Collaborator

ErisDS commented May 7, 2021

I'm so sorry I somehow missed this and then went off on maternity leave. Could we try again?

@AdamPflug
Copy link
Owner Author

@ErisDS sure!

@ErisDS
Copy link
Collaborator

ErisDS commented May 7, 2021

Thank you!

@flipvh
Copy link

flipvh commented Dec 9, 2021

Hi there, this is still a package used by many others. Is there a way to get some updates regarding the dependencies and security warnings? I would be happy to sponsor this effort somehow if possible. Thanks for your consideration.

@animir
Copy link

animir commented Dec 9, 2021

As I see users of this package still suffer because of updates absence.
@flipvh and anyone who wants to keep the logic of this package could migrate to ExpressBruteFlexible from rate-limiter-flexible package.

@flipvh
Copy link

flipvh commented Jan 19, 2022

Thanks @animir we are planning for this somewhere this month! Thanks for all your work and input in all this!

@pjonsson
Copy link

Let's start with the dependency updates and underscore->lodash swap for the first push.

@AdamPflug I don't think anyone is asking for a 2.0, but there is a dependency update in #92, so a 1.0.2 release just containing that would be lovely.

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