lob / hapi-rate-limiter Goto Github PK

Hello, is it possible to use multiple rate limiter like limit 10 requests in a minute and 1000 each day ? Can I just register twice this plugin with different option? Thanks

Error

[1] "register" must be a Function
    at Object.exports.apply (/Users/somewhere/else/node_modules/hapi/lib/config.js:22:10)
    at internals.Server.register (/Users/somewhere/else/node_modules/hapi/lib/server.js:399:31)
    at init (/Users/somewhere/else/server.js:87:10)
    at <anonymous>
    at process._tickCallback (internal/process/next_tick.js:188:7)
    at Function.Module.runMain (module.js:695:11)
    at startup (bootstrap_node.js:191:16)
    at bootstrap_node.js:612:3
(node:2539) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.
    at emitWarning (internal/process/promises.js:92:15)
    at emitPendingUnhandledRejections (internal/process/promises.js:109:11)
    at process._tickCallback (internal/process/next_tick.js:189:7)
    at Function.Module.runMain (module.js:695:11)
    at startup (bootstrap_node.js:191:16)
    at bootstrap_node.js:612:3

While implementing this plugin I found that returning the response code of 500 is not fitting for the API based rate-limiting in general. Typically you would want the response code to be a 429 Too Many Request.

Would you consider allowing for adjustments based on configuration for the status code. The example below allows for defining the status code within plugin settings however defaults to 429 or which ever you prefer.

Example response adjustment:

      if (remaining < 0) {
        debugger;
        return reply.response(options.overLimitError(rate)).code(options.errorStatusCode ? options.errorStatusCode : 429);
      }

Thanks for providing this module. Look forward to hearing your response.

I'm trying to define a dynamic rate limit based upon the user's role.
To achieve this, the user details has to be fetched from db (redis) and then evaluated via async/await.

customRate = async(request){
// read the details from db/cache
 user = await getUserDetails(request.auth.credentials.id);
 if(user.isAdmin){
   return {limit: 10, window: 60};
 }
 return {limit : 5, window: 60};
}

server.route([{
  method: 'POST',
  path: '/custom_rate_route',
  config: {
    plugins: {
      rateLimit: {
        enabled: true
        rate: (request) => customRate
      }
    },
    handler: (request) => {
      return { rate: request.plugins['hapi-rate-limiter'].rate };
    }
  }
}]);

However, defining such an async function throws an error

node_redis: Deprecated: The EVALSHA command contains a "undefined" argument.
This is converted to a "undefined" string now and will return an error from v.3.0 on.
Please handle this in your code to make sure everything works as you intended it to.

I'm guessing the function does not expect a promise. How do we solve this scenario?

This plugin currently can only be used for rate limiting on a route-by-route basis, but if it allowed custom Redis keys it could be used to enforce different rate policies (like rate limiting on an application level). An optional function could be passed into the plugin that returns the key that Redis should use when keeping track of API requests. If no function is passed, then the default behavior could be to fall back to limiting on a route-by-route basis.

options: {
    redisKey: (request) => redisKey,
}

const key = options.redisKey ?
      options.redisKey(request)  :
      `hapi-rate-limit:${request.route.method}:${request.route.path}:${options.requestAPIKey(request)}`;

I can also make a PR for this that adds this feature with some unit tests.

It'd be useful to have the option to whitelist certain API keys so that requests made with those keys don't get rate limited. For example, if I have some services that need to consume each other, I don't want to worry about limiting my own services.

I could pass a defaultRate function that returns an unreachable rate for requests made by my own services, but ideally I wouldn't want to go through Redis if I can identify an API key I don't want to limit.

Something like this would work I think:

options: {
    whitelist: [ 'myAPIKey', 'anotherKey' ],
}

if (options.whitelist && options.whitelist.indexOf(options.requestAPIKey(request)) > -1) {
  return reply.continue();
}

If this is something y'all would like to include in this plugin, I'd be happy to make a PR that adds this feature and the accompanying unit tests.