Let the configured integration proxy live on a private network

TESTING_COVERAGE.md

@@ -221,7 +221,18 @@ that an installation with no app agent on this node is refused before
 connecting, and that other loopback origins stay refused even when a manifest
 declares them. `plugins::egress` tests pin the exception to exactly the
 configured origin (another port, the other scheme, another loopback address,
-`localhost` for `127.0.0.1`, and credentials in the URL are all refused).
+`localhost` for `127.0.0.1`, and credentials in the URL are all refused). They
+also use a table resolver to check that a proxy *name* may resolve to a
+private, CGNAT, ULA or loopback address (`host.docker.internal`, a LAN host),
+resolved once and pinned, while another name, port or scheme resolving to the
+same address is refused, and link-local/metadata is refused even when it is
+the configured proxy. End to end, `it plugin_proxy` starts a real server with
+`--integration-proxy-url` pointing at a loopback stub, pins and installs a JS
+release over HTTP, runs it through `POST /plugin-run`, and checks that
+`ctx.http("atomic-proxy:/demo/items")` arrives as `GET
+/proxy/conn-1/demo/items` with a v2 signature from the installation's node
+agent, that the plugin gets the stub's response, and that an undeclared
+platform is refused before connecting.
 `app_endpoints_test::an_active_installation_reports_its_agent_on_this_node`
 checks `GET /app-agent` reports the identity activation mints for a JS
 Installation. Not covered: a real integration proxy (atomic-plugins#122)

docs/src/plugins/creating-plugins.md

@@ -127,6 +127,7 @@ Every field except `schemaVersion` is optional; unknown fields and malformed dec
 - `secrets`, `operations`, `actions`: as in schema version 1. Secrets name an exact origin a credential may be sent to; operations are exact endpoints with an `effect` of `read` or `write`; actions reference operations.
 - `network.origins`: exact origins (no wildcards, paths or ports beyond the origin) for packages that call the host `fetch` without an operation id. It never widens what `operations` grant.
 - `proxy`: integration-proxy platforms the plugin uses, for example `["clockify"]`, also accepted in schema version 1. The plugin calls `ctx.http` with a proxy-relative URL such as `atomic-proxy:/clockify/api/v1/user`, and the operation that admits it is declared with that URL too. The server resolves it to `{--integration-proxy-url}/proxy/{connection_id}/clockify/api/v1/user`, taking the connection id from the Installation's `integrationConnections` (also passed to the plugin as `ctx.connections`), and signs it as the node's agent for the installation. A request is refused when the platform is not declared, when no connection is delegated for it, or when the node has no proxy configured. Calling the proxy by its absolute URL still works but is deprecated.
+  The proxy the operator configures with `--integration-proxy-url` (`ATOMIC_INTEGRATION_PROXY_URL`) may live on this machine or a private network, such as `http://host.docker.internal:8787` or `http://proxy.lan:8787`: exactly that scheme, host and port may resolve to loopback, private, carrier-grade NAT or IPv6 unique-local addresses, which every other plugin destination is refused. The name is resolved once per request and the host connects to exactly the addresses it checked. Link-local and cloud-metadata addresses (`169.254.0.0/16`, `fe80::/10`, Alibaba's `100.100.100.200`, AWS's `fd00:ec2::254`) are refused even for the proxy, and credentials in the URL are refused.
 - `configSchema`, `defaultConfig`: objects, as in `plugin.json`.
 - `name`, `namespace`, `version`, `description`, `author`: metadata. `name` and `namespace` must be safe path segments.
 

server/src/config.rs

@@ -90,8 +90,12 @@ pub struct Opts {
     /// The integration proxy's origin, e.g. https://localthought.io or, for a proxy on this
     /// machine, http://localhost:8080 — exactly the proxy's own BASE_URL. A server-side plugin's
     /// `ctx.http` requests to this origin are signed with this node's app agent for its
-    /// installation (Atomic v2 request signatures), and a loopback origin is let through the
-    /// public-address check for exactly this scheme, host and port. Omit to configure none.
+    /// installation (Atomic v2 request signatures). Exactly this scheme, host and port may be
+    /// on loopback or a private network (e.g. http://host.docker.internal:8787 or
+    /// http://proxy.lan:8787), which every other plugin destination is refused; the name is
+    /// resolved once per request and the checked addresses are the ones connected to.
+    /// Link-local and cloud-metadata addresses (169.254.0.0/16, fe80::/10, 100.100.100.200,
+    /// fd00:ec2::254) are refused even here. Omit to configure none.
     #[clap(long, env = "ATOMIC_INTEGRATION_PROXY_URL")]
     pub integration_proxy_url: Option<String>,