[Enhancement] Support http://*.onion in cors.allowedOrigins #46

Summary

Tor and other .onion frontends call the IPFS Node REST API from the browser with an Origin of http://<hidden-service>.onion. Today each onion must be listed as an exact entry in cors.allowedOrigins. When a messenger or site hidden service is re-keyed, operators must update every IPFS node config in sync.

A wildcard entry such as http://*.onion is the natural fix, but the current CORS parser rejects it at startup because validateHostname() requires a dot in the wildcard suffix (onion alone fails).

Current behavior

• Wildcard rules use the form https://*.example.org and match any-depth subdomains of example.org.
• http://*.onion fails during config load with Invalid wildcard CORS hostname: onion (see validateHostname() in src/security/cors.ts).
• Operators work around this by adding exact origins, for example Tor PWA hidden services on mainnet deployments.

Observed in production (ADAMANT mainnet, 2026-09-28)

• IPFS hidden services on ipfs4/ipfs6 (z455…onion, 3ytwoe62…onion) proxy to the same ipfs-node API as clearnet nginx.
• The Tor messenger PWA is served from a different onion (for example adamant6457join…onion), not from the IPFS HS hostnames in wallets / tor.json.
• When the PWA origin is listed exactly, GET /api/node/info returns Access-Control-Allow-Origin for that onion and probes succeed over Tor.
• Tor Browser (Firefox) often sends Origin: null (not the PWA onion) on cross-.onion fetches from the PWA to the IPFS onions. The API still returns HTTP 200, but without Access-Control-Allow-Origin, so the client reports CORS failure and nodes show Offline. This is separate from the wildcard issue: it needs an explicit null entry in cors.allowedOrigins (literal four-character string) or a client-side change. Document the trade-off (any opaque origin) in security docs.

Proposed behavior

• Accept http://*.onion (and optionally https://*.onion if ever used) as a wildcard suffix rule.
• Match browser origins whose hostname is a valid v3 onion name (56-character base32 label + .onion) or a subdomain thereof, using the same path/port/credentials rules as existing HTTP(S) wildcards.
• Reject bare http://*.onion paths with userinfo, query, fragment, or non-canonical forms, consistent with other CORS entries.
• Document the rule in docs/guide/configuration.md and docs/guide/security.md, and mention it in the Adamant Messenger integration guide where Tor PWA origins are discussed.
• Document the optional null origin entry for Tor Browser cross-onion behavior alongside Tor wildcard guidance.

Security and scope

• This is an explicit deployer opt-in; default config.default.json5 should keep Tor onions commented or absent so new standalone deployments do not open CORS to all .onion sites by default.
• Wildcard .onion is broader than a single HS hostname but still limited to the .onion namespace (not public clearnet). Call out in docs that any Tor site the user can reach could call the API if the node is reachable.
• The null entry is broader still (any opaque browser origin). Keep it commented in defaults; mention it only for meshes that must support Tor Browser cross-onion clients until the client or browser behavior changes.
• Do not add a bare * or relax non-onion wildcards.

Acceptance criteria

• cors.allowedOrigins containing http://*.onion passes validateConfig and starts the server.
• createOriginMatcher returns true for representative Tor PWA and IPFS onion origins and false for unrelated hosts (for example https://evil.example.org, http://short.onion).
• Unit tests cover parsing, matching, and rejection of malformed entries.
• Configuration and security docs list the new pattern alongside existing wildcard rules.
• Adamant Messenger guide mentions Tor PWA http://*.onion and the Origin: null case.

Related context

• Desktop Electron clients use exact app://. origins (see closed [Composite] Close 0.1.0 adoption gaps: desktop CORS, proxy docs, upload diagnostics #44 / PR Fix: Allow desktop CORS and name upload failures #45).
• Production ADAMANT meshes temporarily listed exact Tor PWA onions in node config until this enhancement ships.
• Implementation can ship in the same change set as null origin support if maintainers agree; keep them documented as separate opt-in entries.