You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, to test rack-attack's behavior we need to use something like:
context"number of requests is lower than the limit"doit"does not change the request status"do1000.timesdoget"/",{},"REMOTE_ADDR"=>"1.2.3.4"expect(last_response.status).to_noteq(429)endendend
to perform a lot of unneeded requests (depending on the throttling configuration) or use some internals from the gem like:
defemulate_previous_requests(key,count:,period:)# Go to the rack-attack's internals to make tests faster.key,expires_in=Rack::Attack.cache.send(:key_and_expiry,key,period)Rack::Attack.cache.store.write(key,count,expires_in: expires_in)end# and use the `emulate_previous_requests` helper in tests
This can be also solved by using some constants in the rack-attack configuration block and then assign some smaller numbers to these constants in the testing environment, but this is ugly if we have a lot of different constants.
It would be nice to have some test helpers to simplify write the tests.
I can help with this, but needs to figure out the API.
The text was updated successfully, but these errors were encountered:
This request help me work around a related problem... We found that some of our tests can fail if they happen to run during the time rack attack has chosen as the expiry.... Since it seems like the expiry is chosen based on a modulus of time...
def sleep_if_required(interval)
# rack attack uses a modulus of time to choose when to rest things...
# https://github.com/rack/rack-attack/blob/d7a7a8bda5cba232d8d5d300b95cef79d40cc528/lib/rack/attack/cache.rb#L69
# so if we are running when the reset is going to happen... our test can fail :(
# so if it looks like we are going to be close... sleep until the start of the new period
mod = Time.now.to_i % interval
dif = interval - mod
if dif < 2
puts "sleeping till new rack attack period #{(dif + 1)}"
sleep((dif + 1).seconds)
end
end
Its not a great solution, and i would love some other test helper that could help work around this...
Currently, to test
rack-attack
's behavior we need to use something like:to perform a lot of unneeded requests (depending on the throttling configuration) or use some internals from the gem like:
This can be also solved by using some constants in the
rack-attack
configuration block and then assign some smaller numbers to these constants in the testing environment, but this is ugly if we have a lot of different constants.It would be nice to have some test helpers to simplify write the tests.
I can help with this, but needs to figure out the API.
The text was updated successfully, but these errors were encountered: