Version 2.0 Roadmap

[AdamPflug]

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

• New storage adapter layer
  • Should allow for atomic updates to storage to resolve global bruteforce count is not updating on more than 1000 concurrent requests #46
  • Ideally should generalize the storage adapter layer so that it can be used by other projects as well (not tied directly to express-brute).
  • This will unfortunately require the existing express-brute storage adapters to be updated or replaced, I'm still on the fence on whether it makes sense to create a small "migration" adapter that allows existing storage adapters to be used (without fixing the vulnerability described in global bruteforce count is not updating on more than 1000 concurrent requests #46 fixed) until suitable replacements/updates can be developed. May be better to protect people from themselves there.
• Separate out the core code from the code that interacts with express.
  • This enables me to develop a koa version as well (which would be nice because I rarely use express for new projects at this point)
  • This should also let people use the underlying rate-limiting functionality in more customized ways if they need to (Make getMiddleware able to read status of other route #28, Ability to query status without incrementing #22)

Minor Improvements

• Optimize hash calculation and allow it to be bypassed/overwritten (Consider using xxhash vs sha256 #70)
• Add the option to attach the number of remaining requests to the request object (Retrieve number of remaining requests #73)
• Look at standardizing the options between the constructor and getMiddleware() (options on getMiddleware #64, getMiddleware options are different than constructor options #20)

[AnandChowdhary]

@AdamPflug Do you have a rough timeline for this?

[AdamPflug]

@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]

@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]

@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]

@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]

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]

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]

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]

@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]

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

[AdamPflug]

@ErisDS sure!

[ErisDS]

Thank you!

[flipvh]

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.