[6/6] Attribute requests to a caller and a client tool

[wickedOne]

Client and request-source attribution

Part 6 of six splitting #381 ("analytics dashboard") into reviewable pieces, as the review there asked for -- this is the half it singled out as needing the most thought, now out from behind 3,000 lines of dashboard JSON. #381 can be closed once this lands.

Series: #388 route coverage · #389 ecosystem stats · #390 analytics page · #391 /stats breakdown · #392 Grafana dashboard · #393 source attribution

Needs #389, #390 and #392, and branches off #392, so until the chain merges the Files changed tab here shows those too. The last commit is this part.

Package managers do not say who invoked them. A request from pip or go carries a Host, an Accept and a User-Agent -- no Referer, no originating URL, nothing naming a repository, pipeline or job. So the proxy attributes requests by the two things always present: the caller's address, and the tool name taken from the leading User-Agent token.

Client names are exported as proxy_client_requests_total{client} and proxy_client_response_bytes_total{client} because they come from a closed set -- a User-Agent is attacker-controlled, so anything unrecognised collapses to other rather than minting a time series per request. Addresses are not exported as labels at all: the caller set is unbounded and outside the proxy's control. Per-address detail lives in the access log and, when enabled, on the page.

ui_request_sources, off by default

The review's point: the sources card publishes caller IP addresses, tool names and per-caller volumes on /ui/analytics, and the proxy has no authentication of its own, with gating deferred to a reverse proxy (#123). Until now /ui exposed what was cached, not who called.

So the card is behind a new top-level ui_request_sources, defaulting to false, and the README says plainly what it exposes and that /ui is unauthenticated. The tracker still runs when the flag is off, so the Prometheus client metrics are unaffected -- only the addresses are withheld. Tests cover both states end to end.

trust_forwarded_for moves to the top level

Also from the review: access_log.trust_forwarded_for reads narrower than it acts, since it drives the structured log and the analytics table as well as the access log. It is now top-level trust_forwarded_for / PROXY_TRUST_FORWARDED_FOR. Nothing has been released with the old key.

The header is honoured only when the flag is set, and the value must parse as an IP: a load balancer that appends leaves the leftmost entry caller-controlled, and that string becomes a map key held for the process lifetime and a line in the access log.

Log fields

remote keeps its meaning. #381 changed it from host:port to host-only; per the review it stays as the TCP peer and a new remote_ip carries the attributed address, matching what accesslog.Entry already does with RemoteAddr/RemoteIP. The access log gains remote_ip, user_agent, client, ecosystem and bytes.

The table

It tracks 200 callers, evicting the least recently seen once full. Evicting rather than refusing matters in the deployment this is for: containerised CI gives every job a fresh address, so a refusing table would freeze on whoever arrived first.

The overflow row reports two counts separately -- callers currently tracked below the display cut, and fold-ins from eviction -- because only the first is exact. A caller evicted, returning and evicted again counts twice, and counting distinct callers instead would mean keeping every key ever seen, which is the unbounded set the limit exists to avoid.