- Renamed all instances of 'Activity' to 'Job' in views, controllers, and models.
- Updated routes to reflect the change from activities to jobs.
- Modified database schema to rename the activities table to jobs and adjusted related columns.
- Updated locale files to change activity-related translations to jobs.
- Adjusted tests to ensure they reference jobs instead of activities.
- Removed the category field from jobs as they are now a plain list.
- Updated seed data and sample data generation to create jobs instead of activities.
/api/v1/activities is the single busiest route in production: 216 of 1101
requests in a 14 minute log window, 19.6% of all traffic and 21.7% of
non-asset traffic. It was the only high-volume route with no rate limit,
since the throttle matched plantings, harvests and members only.
Collapses the two alternations into one regex with an optional /api/v1
prefix, so the HTML and API routes stay in step instead of being listed
twice. Verified equivalent to the old pair across both route families
plus their edge cases: /plantingsfoo, /memberships, /foo/plantings and
/api/v2/activities are still unmatched.
Note this does not by itself stop the client currently polling that
endpoint. It makes 189 requests over 21 minutes, about 9 per minute,
which is under the 15 per minute limit, and Rack::Attack counters live
in per-worker memory so at WEB_CONCURRENCY=2 each worker sees only half
of them. This closes the hole rather than fixing today's load.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
* Keep Rack::Attack counters in process memory
Rack::Attack was storing its request counters in Rails.cache, which is
memcached in production. On 2026-09-19, memcached calls were timing out
in the production logs. When that happens, the counters stop working.
In the same log window, one IP made 753 requests. 717 of them
succeeded. The 15 per minute throttle and the 500 per day ban did not
stop it.
Rack::Attack now uses its own in-memory store, capped at 8 MB. Each
Puma worker keeps its own counters, so the limits apply per worker.
Refs #1640
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
* Add BLOCKED_IPS list to Rack::Attack
When one crawler overloads the site, we need a fast way to block it.
Rack::Attack now blocks every IP listed in the BLOCKED_IPS environment
variable. The list is comma separated.
Setting the variable does not need a code change. It also keeps IP
addresses out of the repository.
Refs #1640
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
* Lower the memcached socket timeout to 0.5 seconds
The production cache store waited up to 1.5 seconds for each memcached
call. Dalli's own default is 1 second. Dalli also retries after a
failure, so one bad cache call can block a Puma thread for longer than
the timeout.
On 2026-09-19, the production logs showed memcached timeouts every few
seconds. With only 5 threads per Puma worker, blocked threads make the
site slow. Slow requests hold memory for longer.
The timeout is now 0.5 seconds. A healthy memcached call takes a few
milliseconds. A call that takes 0.5 seconds has failed in practice, so the
request is better off skipping the cache.
Refs #1640
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
---------
Co-authored-by: Claude Sonnet 5 <noreply@anthropic.com>
- Configure Allow2Ban in Rack::Attack to ban IPs requesting >500 pages per day for 1 week (7 days).
- Add honeypot route /dont-crawl-me disallowed in robots.txt and configure Fail2Ban in Rack::Attack to ban IPs visiting it for 7 days upon 1 hit.
- Update PhotosController#index to raise ActiveRecord::RecordNotFound when page parameter is out of bounds, returning 404 Not Found to crawlers instead of 200 OK.
- Add request and controller specs for Rack::Attack rules and pagination 404 responses.
Co-authored-by: CloCkWeRX <365751+CloCkWeRX@users.noreply.github.com>
Brenda Wallace