ipx's clients had no destination policy and followed redirects anywhere. Adding a feed returned the status or first line of whatever answered at the address; an enclosure declared as audio was downloaded whole from any URL and served back through /media; /api/art fetched any image a feed named. Feeds come from publishers and anyone signed in, so loopback, the Docker network and the LAN were all reachable. ipx-feed's guard is a connector layer: after the name resolves and the connection opens, before the request is written, it looks at the peer's address and refuses anything off the public internet unless config.toml's [general] fetch_internal lists it. Being on the connection, it covers every request on ctx.client and feed_client, each redirect hop, IP literals (which never reach a DNS resolver) and a name that resolves differently the second time. reqwest's rustls connection reports the peer address; a test run by hand checks HTTPS gets through, since were it lost every https fetch would be refused. The directory is on the server's own network by design (http://ipx-directory:8100), so it moves to local_client, unguarded, set by an admin. The browser suite and load tests serve their feeds on loopback and list 127.0.0.1. Not covered: librqbit's own connections (trackers, peers), which do not go through these clients. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
3.3 KiB
3.3 KiB