checkClient read the time once, before the lookup, which can wait for GeoJS up to SWWAF_LOOKUP_TIMEOUT while a country list, SWWAF_ADD_LOOKUP_HEADERS or a biased threshold is set, and the rate limits counted the request at that time. Two requests of a new client that waited across the end of a minute could be counted out of order. When the earlier one was dated more than a second before the minute under way began, Buckets.Add took it for a clock set back and started the minute afresh, so the other request dropped out of counts and of the limit. The checks after the lookup now read the time again; the ban check before it keeps the time read first.
What the diff does not show:
The time read after the lookup is also the time of the CrowdSec check, of a ban for a broken limit, a trap path or a ban rule, and of the request in that ban's notes. The log line's time is still when the request arrived.
The test fixes the order rather than leaving it to the scheduler: it keeps the client's answer with GeoJS.Load, as an edit of lookups.json would, so the second request goes on while the first still waits for the held GeoJS.
No sentence of README.md or SPEC.md changes: both already describe the counts this gives.
Model: opus-5-5
Fixes https://git.eeqj.de/sneak/smallwebwaf/issues/129.
`checkClient` read the time once, before the lookup, which can wait for GeoJS up to `SWWAF_LOOKUP_TIMEOUT` while a country list, `SWWAF_ADD_LOOKUP_HEADERS` or a biased threshold is set, and the rate limits counted the request at that time. Two requests of a new client that waited across the end of a minute could be counted out of order. When the earlier one was dated more than a second before the minute under way began, `Buckets.Add` took it for a clock set back and started the minute afresh, so the other request dropped out of `counts` and of the limit. The checks after the lookup now read the time again; the ban check before it keeps the time read first.
What the diff does not show:
- The time read after the lookup is also the time of the CrowdSec check, of a ban for a broken limit, a trap path or a `ban` rule, and of the request in that ban's notes. The log line's `time` is still when the request arrived.
- The test fixes the order rather than leaving it to the scheduler: it keeps the client's answer with `GeoJS.Load`, as an edit of `lookups.json` would, so the second request goes on while the first still waits for the held GeoJS.
- No sentence of README.md or SPEC.md changes: both already describe the counts this gives.
Model: opus-5-5
checkClient read the time before the lookup, which can wait for GeoJS
up to SWWAF_LOOKUP_TIMEOUT, and the rate limits counted the request at
that time. Two requests of a new client waiting across the end of a
minute could then be counted out of order, and the one dated more than a
second before the minute under way began made the rate limits start
that window afresh, as for a clock set back: the other request's count
was lost. The checks after the lookup now read the time again.
Model: opus-5-5
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Fixes #129.
checkClientread the time once, before the lookup, which can wait for GeoJS up toSWWAF_LOOKUP_TIMEOUTwhile a country list,SWWAF_ADD_LOOKUP_HEADERSor a biased threshold is set, and the rate limits counted the request at that time. Two requests of a new client that waited across the end of a minute could be counted out of order. When the earlier one was dated more than a second before the minute under way began,Buckets.Addtook it for a clock set back and started the minute afresh, so the other request dropped out ofcountsand of the limit. The checks after the lookup now read the time again; the ban check before it keeps the time read first.What the diff does not show:
banrule, and of the request in that ban's notes. The log line'stimeis still when the request arrived.GeoJS.Load, as an edit oflookups.jsonwould, so the second request goes on while the first still waits for the held GeoJS.Model: opus-5-5
PASS: reading the time again after the lookup fixes #129 at its cause.
Model: opus-5-5