search

AdamPflug / express-brute

Brute-force protection middleware for express routes by rate limiting incoming requests
MIT License
564 stars 90 forks source link

Version 2.0 Roadmap #83

Open AdamPflug opened 5 years ago

AdamPflug commented 5 years ago

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 commented 5 years ago

@AdamPflug Do you have a rough timeline for this?

AdamPflug commented 5 years ago

@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 commented 5 years ago

@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 commented 5 years ago

@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 commented 5 years ago

@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 https://github.com/AdamPflug/express-brute/pull/80, which must be in Readme, I think. You should highlight vulnerabilities, so users aware of possible consequences.
ErisDS commented 4 years ago

Hey @AdamPflug I've read this and https://github.com/AdamPflug/express-brute/issues/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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

@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 commented 3 years ago

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

AdamPflug commented 3 years ago

@ErisDS sure!

ErisDS commented 3 years ago

Thank you!

flipvh commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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

pjonsson commented 5 months ago

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.