RFC: Issues with multiple Attack instances in the same process / Rack stack (class ivar binding)

[julik]

I would like to use multiple instances of Rack::Attack in the same Rack stack, but in different places. Each one of these would accept it's own throttles, blacklists etc. Judging from the code, I assumed I could do

 class MyThrottle < Rack::Attack
    throttle(...) do |req|
      ...
    end
 end

It turned out, however, that the method performing the throttling still reaches into the attribute reader of the superclass, and thus finds throttles defined on the parent instance. I think the same is the case for blacklisting and whitelisting, but I don't necessarily need them in this specific application. I was only able to make throttles work in a subclass by doing

 class MyThrottle < Rack::Attack
    ...
    def throttled?(req)
      self.class.throttles.any? do |name, throttle|
        throttle[req]
      end
    end
 end

This stems from the fact that some smart machinery is involved in making the configuration available on the class level. I think that it might make more sense if the same configuration could be applied with, say, options (since block handling with middleware attachment is not that well understood):

 my_attack_config = Rack::Attack::Config.new do |c|
    c.throttle(...) do |req| # etc
      ...
    end
 end
 use Rack::Attack, config: my_attack_config

So I think there was some thought given to separating the various classes' configurations within one Ruby process, but this was not really tested. You could in theory alter the throttled? etc. methods to call into the right class for the variables and consider this a bug, but maybe the API can just be improved and handle this explicitly?

[ktheory]

I would like to use multiple instances of Rack::Attack in the same Rack stack, but in different places

Interesting idea, though I'm trying to understand the motivation. Can you explain your use-case a bit more?

[julik]

We are using multiple Rack apps within our Rails monolith. Within some of these apps we would like to throttle based on some context that does not get set up globally, but gets set up only within that particular app (mostly API endpoints). This means that we need to have lots if ifs if we want to apply these throttles globally - to check for all the maybe-present custom rack environment keys.

[grzuy]

It sounds like something worth trying.

[jellybob]

We're seeing similar issues, in our case there are some throttles we can apply without any user details. We then hit an internal service to get additional information about the connecting user, then apply any rate limits which require things like the list of user roles applied to their account.

We've worked around it with a middleware inserted after the first phase which deletes the key rack.attack.called from the env hash before moving on, and a monkey patch to Rack::Attack which allows passing a pre-populated configuration object to the initializer. This is an unpleasant pile of hacks I'm convinced are going to break at any moment though so it would be nice to have something better supported.