Limit each client's requests to the image routes (closes #236)

The new setting image_requests_per_minute (PIXA_IMAGE_REQUESTS_PER_MINUTE),
default 600, caps the GET and HEAD requests one client sends to /v1/image/
and /v1/e/ per minute; the next is answered 429 with Retry-After. It uses
the login limit's RateLimit middleware, so clients are told apart the same
way, and sits in the image routes' group behind the CORS middleware, so a
preflight is not counted. 0 turns it off; a negative or non-integer value
stops startup.

TestEnvironmentSetsEveryKey gains the new variable, under the owner's
standing approval in #64. To stay
within the linters' limits, the sentry_dsn check moves unchanged into
validateSentryDSN, and the cache_max_bytes explicit flag is set in one
line.

Model: opus-5-5

README.md

@@ -46,9 +46,9 @@ everything in this list without further settings. The reverse proxy must:
   builds encrypted URLs from `Host`, and checks `Referer` against
   `referer_blocklist`;
 - set `X-Forwarded-For` to the client's address, with `trusted_proxies` set to
-  the address pixa sees the proxy's requests come from, so the login limit
-  counts each client by its own address (see `trusted_proxies` under
-  Configuration);
+  the address pixa sees the proxy's requests come from, so the login limit and
+  `image_requests_per_minute` count each client by its own address (see
+  `trusted_proxies` under Configuration);
 - wait for pixa's answer for at least `downstream_timeout` (default `60s`), the
   longest pixa takes to fetch, convert and send an image.
 
@@ -58,8 +58,9 @@ password there.
 
 pixa does the rest itself: it checks signatures and encrypted URLs, applies the
 allowlist, refuses upstream hosts with private or local addresses, limits login
-attempts, upstream response size and image dimensions, and sends the security
-headers, `Strict-Transport-Security` included, with every response.
+attempts, each client's image requests, upstream response size and image
+dimensions, and sends the security headers, `Strict-Transport-Security`
+included, with every response.
 
 The state directory (`state_dir`, `/var/lib/pixa` in the container) holds the
 database and the disk cache:
@@ -186,10 +187,10 @@ path under `/v1/` answers 200, in maintenance mode too.
   `Referer` names a host in `referer_blocklist`, checked before the signature,
   the cache and the upstream fetch; 403 when the upstream host, or a host it
   redirects to, is `localhost`, ends in `.localhost` or `.local`, or has an
-  address in a blocked network (see `blocked_networks`); 502 when the upstream
-  answered with an error status, and for 5 minutes after that for the same
-  source URL; 503 when pixa is busy or in maintenance mode; 500 for any other
-  failure.
+  address in a blocked network (see `blocked_networks`); 429 over
+  `image_requests_per_minute` (below); 502 when the upstream answered with an
+  error status, and for 5 minutes after that for the same source URL; 503 when
+  pixa is busy or in maintenance mode; 500 for any other failure.
 - `GET` or `HEAD` `/v1/e/<token>/<name>` — an image through an encrypted URL
   (see Encrypted URLs). Needs: nothing but the URL. Answers: 200; 304 when
   `If-None-Match` matches the image's `ETag`; 400 for a token that does not
@@ -197,7 +198,7 @@ path under `/v1/` answers 200, in maintenance mode too.
   expired; 504 when the upstream has not sent its response headers within
   `upstream_fetch_timeout`, but 500 when that time runs out while the image
   itself is still arriving; 400 for an `Accept` header that is not valid, and
-  406, 403, 502, 503 and 500, as for `/v1/image/`.
+  406, 403, 429, 502, 503 and 500, as for `/v1/image/`.
 - `GET /robots.txt` — asks every crawler to stay away (`Disallow: /`). Needs:
   nothing. Answers: 200.
 - `GET /.well-known/healthcheck.json` — JSON with `status` (`ok`), `now`,
@@ -313,6 +314,14 @@ its own `X-Forwarded-For`, whether it connects directly or through the proxy,
 because its own address is trusted too. Setting `trusted_proxies` to only the
 address pixa sees for requests that come through the proxy closes this.
 
+One client may send `image_requests_per_minute` requests per minute
+(default 600) to the image routes, `/v1/image/` and `/v1/e/` together, `GET` and
+`HEAD`, cache hits included; a request over the limit is refused with 429 and a
+`Retry-After` header. Clients are counted as for the login limit. A browser's
+CORS preflight is not counted. Behind a CDN or proxy whose addresses are not in
+`trusted_proxies`, every request counts as the same client, so such a deployment
+needs a higher limit, or `0`, which turns the limit off.
+
 ### Encrypted URLs
 
 An encrypted URL is an image URL made on pixa's own web page by someone who
@@ -482,6 +491,7 @@ tell. With no file, pixa uses the environment and the defaults.
 | `PIXA_UPSTREAM_CONNECTIONS_PER_HOST` | `upstream_connections_per_host` | Concurrent connections per upstream host; default `20`                       |
 | `PIXA_UPSTREAM_CONNECTIONS`          | `upstream_connections`          | Concurrent connections to all upstream hosts together; default `64`          |
 | `PIXA_MAX_CONCURRENT_PROCESSING`     | `max_concurrent_processing`     | Images processed at once; default the number of CPUs                         |
+| `PIXA_IMAGE_REQUESTS_PER_MINUTE`     | `image_requests_per_minute`     | Image requests per client per minute; `0` turns it off; default `600`        |
 | `PIXA_UPSTREAM_FETCH_TIMEOUT`        | `upstream_fetch_timeout`        | Time allowed for one fetch from an upstream host; default `30s`              |
 | `PIXA_UPSTREAM_MAX_RESPONSE_SIZE`    | `upstream_max_response_size`    | Largest upstream response accepted, in bytes; default 50 MiB                 |
 | `PIXA_DOWNSTREAM_TIMEOUT`            | `downstream_timeout`            | Time allowed for answering one client request; default `60s`                 |
@@ -531,13 +541,13 @@ Key settings in more detail:
   explicit list replaces the default. An invalid CIDR aborts startup. Set this
   to the address pixa sees for requests that come through your proxy, such as
   `172.17.0.1/32`, when the defaults do not cover it, or to trust nothing else
-  (see the login limit under Routes). For a proxy on the Docker host that
-  connects to pixa over `127.0.0.1`, that address is the gateway of the
-  container's Docker network (`172.17.0.1` on the default bridge), not the
-  proxy's own address; a proxy that connects through another of the host's
-  addresses is seen with that address. To be sure which address it is, set this
-  to `[]` (or `PIXA_TRUSTED_PROXIES` to empty), send a request through the
-  proxy, and read `remoteIP` in pixa's request log line for it
+  (see the login limit and `image_requests_per_minute` under Routes). For a
+  proxy on the Docker host that connects to pixa over `127.0.0.1`, that address
+  is the gateway of the container's Docker network (`172.17.0.1` on the default
+  bridge), not the proxy's own address; a proxy that connects through another of
+  the host's addresses is seen with that address. To be sure which address it
+  is, set this to `[]` (or `PIXA_TRUSTED_PROXIES` to empty), send a request
+  through the proxy, and read `remoteIP` in pixa's request log line for it
 - `upstream_fetch_timeout` — time allowed for one fetch from an upstream host,
   as a duration such as `30s` (the default) or `2m`
 - `upstream_max_response_size` — largest upstream response accepted, in bytes;
@@ -570,6 +580,11 @@ Key settings in more detail:
   container's CPU limit. A request that finds all of them in use waits up to 10
   seconds for one to free up; if none does, and `downstream_timeout` has not
   ended first, it is answered 503 the same way
+- `image_requests_per_minute` — how many requests one client may send to the
+  image routes per minute (see the limit on them under Routes); default `600`.
+  `0` turns the limit off, and a negative or non-integer value aborts startup.
+  Behind a CDN or proxy whose addresses are not in `trusted_proxies`, every
+  request counts as the same client, so raise the limit there, or set `0`
 - `maintenance_mode` — while `true`, the image routes (`/v1/image/` and
   `/v1/e/`) answer every request for an image with 503, a `Retry-After` header
   and a JSON error body. The health check (`/.well-known/healthcheck.json`)