Releases

• Admin > Modules now shows Configure next to Traffic Guard. It opens Admin > Traffic Guard > Settings, which has every setting.
• Removed the short settings form at /admin/module/configure?id=TrafficGuard. Saving it reset Log allowed requests too to off and Events per page to 50, because those fields were not on it.

• Editors and other roles below Supervisor who open a Traffic Guard page now get Omeka's Forbidden page with HTTP status 403. They used to get Omeka's error page Omeka S encountered an error with status 500. Apart from bans (below), who may use each page is unchanged.
• Supervisors can no longer place or lift bans, as the documentation always said: only Global Admins can. Omeka grants Supervisors everything it is not told to refuse them, so they could ban and unban IPs. The IP page now lists the active bans for them without the Ban IP and Lift Ban buttons, and a ban or unban request gets the Forbidden page. Give the Global Admin role to anyone who still needs to manage bans.

• Bans and the dashboard now work on servers whose MySQL time zone is not UTC. Times are stored in UTC, but bans and the "last 24 hours" were checked against MySQL's NOW(), which follows the connection's time zone: east of UTC new automatic bans never took effect, west of UTC expired bans stayed active for hours and the 24-hour counts covered more than a day, and lifted bans recorded a local time. Every comparison now uses UTC from PHP's clock, the same clock the times are written with (also the IP page's "currently banned" check and the purge of old bans).
• The Settings page's auto-ban duration no longer says "0 = permanent": automatic bans are always temporary, so the field now starts at half an hour. Permanent bans are placed by hand.
• New mcp endpoint category for the MCP Server module (/mcp, its upload and OAuth URLs, and the /.well-known/oauth-* and /.well-known/openid-configuration discovery documents), with its own rate limits (240 / 120 / 60 requests per minute in Normal / Elevated / Under Attack). User-agent heuristics (empty or bot-like user agents such as curl/) are skipped for this category, since MCP clients are programs that authenticate with API keys; rate limits, bans and admin-defined user-agent rules still apply.

First published build of Traffic Guard. This release contains the complete feature set of the module:

• Early request interception on every public request, before any controller or database query runs. Abusive requests receive a plain-text HTTP 429 (with Retry-After: 60) or HTTP 403 response.
• Risk scoring from 0 to 100 built from additive signals: empty user agent, known bad-bot user-agent patterns, admin-defined user-agent block rules, rate-limit proximity (soft at 80 percent, hard above 100 percent), deep pagination (page greater than 50) and very long search query strings. Throttle and block thresholds are configurable per protection mode.
• Per-IP rate limiting with 60-second fixed windows for four endpoint categories (all public, search, API, item/media pages). Admin paths are never rate limited.
• Three protection modes (Normal, Elevated, Under Attack) that each carry their own set of rate limits, thresholds and signal weights.
• Automatic temporary bans when a request reaches the block threshold, with a configurable duration, plus manual bans (timed or permanent) and ban lifting from the IP detail page.
• User-agent allow and block rules using case-insensitive substring or regular-expression matching, evaluated in priority order.
• IP allowlist for single addresses and IPv4/IPv6 CIDR ranges, with optional automatic exemption of private and loopback ranges.
• Optional X-Forwarded-For support for installations behind a trusted reverse proxy.
• Event log of throttle and block decisions (allowed requests optional), with a configurable retention period and a background purge job.
• Admin dashboard with 24-hour summary counts, top blocked IPs, active bans and a filterable, paginated event log; per-IP detail page; rules page; settings page; and a short configuration form on the Modules page.
• Fail-open design: any error inside the guard is logged and the request is allowed through, so the module never takes a site offline.