[abercrombie04]

This PR resolves the following assigned issues:

• closes test(deploy): cover DefaultClientFactory wiring #82
• closes refactor(config): register constructor argument types in a table #83
• closes feat(api): configurable CORS for browser dashboards #84

Changes Made

#82 — test(deploy): cover DefaultClientFactory wiring

• Added internal/deploy/client_factory_test.go (new file, owned by this issue) with three test groups:
  • TestDefaultClientFactoryWiresTheNetworkPassphrase — builds a client from a config.Network for testnet and mainnet (using the same passphrase literals as the existing deploy fixtures) and asserts NetworkPassphrase() returns exactly the passphrase configured for that network. This pins the rpc_url → URL and passphrase → NetworkPassphrase field wiring, so a mix-up between the two fields (which would sign transactions for the wrong network) fails immediately.
  • TestDefaultClientFactoryKeepsNetworksApart — builds clients for two networks back to back, the sequence a server serves when consecutive requests deploy to testnet and then mainnet, and asserts neither client picked up the other's passphrase.
  • TestDefaultClientFactoryRejectsInvalidRPCURLs — table of five malformed endpoints (not a url, ://missing-scheme, ftp://example.org, empty string, https:// with no host), each asserting construction returns an error naming the offending value and no client.
• Added a small, additive URL check at the top of DefaultClientFactory (internal/deploy/service.go): parse with net/url, require scheme http/https and a non-empty host, otherwise return invalid RPC URL %q: .... Rationale: stellar.NewRPCClient only rejects an empty string, so any other malformed endpoint survived construction and failed later as an opaque error on the first request; checking in the factory names the bad value while the config file is still open. Construction makes no network call, so the tests need no server and no httptest.
• Test file uses package deploy_test and only the public surface (deploy.DefaultClientFactory, config.Network), matching how other packages' external tests are written.

#83 — refactor(config): register constructor argument types in a table

• internal/config/args.go: replaced the single switch in Arg.ToScVal with one ordered registry, argTypeRegistry []argTypeEntry{name, encode}, populated in init():
  • Each type's encoder is now a named function (encodeBool, encodeU32, …, encodeVec, encodeMap, encodeXDR) registered in exactly one place.
  • SupportedArgTypes is derived from the registry (built in the same init), never a hand-maintained literal — the drift the old design allowed (a type encoded but missing from the message, or listed but never encoded) is now impossible. The current order (bool, void, u32, i32, u64, i64, u128, i128, string, symbol, bytes, address, vec, map, xdr) and therefore every "supported: ..." error message are byte-identical to before.
  • ToScVal normalises the type name with the same strings.ToLower(strings.TrimSpace(...)), keeps the exact missing type (...) and unsupported type %q (... use type: xdr ...) messages, and looks the name up in the registry.
  • vec and map recurse through Arg.ToScVal rather than calling encoders directly, so nested values take the same registry lookup and the same vec[%d] / map[%d].key / map[%d].value error wrapping as top-level ones.
  • The init() pattern is used because the pieces reference each other (registry holds the encoders, vec/map recurse through ToScVal, ToScVal reads the registry and SupportedArgTypes); written as initialization expressions that is a cycle the compiler rejects, and init runs once after all package variables are set with deterministic order.
  • The Arg doc comment now describes the registry workflow instead of "extend the switch".
• internal/config/args_test.go: existing table-driven cases were moved to package-level vars verbatim (zero expectation changes — every pre-existing test passes unchanged, as the issue requires), plus:
  • TestEveryRegisteredArgTypeHasATableCase — asserts every type in argTypeRegistry has at least one case in the table test, so a new type cannot be registered without a test.
  • TestArgToScValContainerTypes — extra nested vec/map coverage exercising recursion through the registry.

#84 — feat(api): configurable CORS for browser dashboards

• internal/config/env.go:
  • New EnvAPICORSOrigins = "SOROFORGE_API_CORS_ORIGINS" and Env.APICORSOrigins (trimmed in LoadEnv; included in Redacted since origins are public).
  • ParseCORSOrigins(raw) — splits the comma-separated value, trims, skips empty entries (a trailing comma is harmless), validates each origin, and errors on any invalid entry so a typo cannot silently disable or widen the policy. Empty input yields no origins, which is how CORS stays opt-in: unset ⇒ exactly today's behaviour of no CORS headers.
  • ValidateCORSOrigin(origin) (exported so api.NewRouter can hold Options to the same rules) — rejects * anywhere with an explicit explanation: SOROFORGE_API_CORS_ORIGINS must not contain "*": list the exact origins the dashboard is served from. It also requires an exact scheme://host[:port]: no path, query, fragment, userinfo, or non-http(s) scheme. Rationale documented in code: the API can deploy contracts with the configured signing key, and browsers compare origins exactly, so accepting a path/trailing slash would configure a list that never matches with CORS silently off.
• internal/api/api.go:
  • Options gains CORSOrigins []string; NewRouter re-validates each origin (library callers get the same refusal at startup as the env var) and returns an error rather than a server.
  • When origins are configured, the chi router is wrapped with github.com/go-chi/cors (new direct dependency, v1.2.1) configured narrowly: AllowedOrigins = the exact list, AllowedMethods = GET, POST (only what routes() declares), AllowedHeaders = Authorization, Content-Type (the bearer token and JSON bodies), MaxAge = 10 minutes, and no AllowCredentials (the API authenticates with a bearer header, not cookies).
  • The middleware wraps the router rather than joining its stack: preflight OPTIONS requests deliberately carry no Authorization header, so the CORS handler answers them before the auth-wrapped routes are ever reached, while actual requests still pass through auth.authorize in full.
• cmd/soroforge/commands.go: the serve command parses SOROFORGE_API_CORS_ORIGINS via config.ParseCORSOrigins and passes the result to api.Options, so a bad value (including *) fails at startup.
• README.md: documented the variable in the environment-variables table plus a "Browser dashboards (CORS)" section with an example, the opt-in rationale, the * refusal, and the preflight-without-token / actual-requests-still-authenticated behaviour.
• go.mod/go.sum: added github.com/go-chi/cors v1.2.1.

Tests

• New/updated coverage: allowed origin echoes Access-Control-Allow-Origin; a disallowed origin gets no CORS header; preflight OPTIONS to a write route with no token returns 2xx with CORS headers (and the handler is never invoked); a tokenless actual request with an allowed origin still returns 401; empty config sends no CORS headers at all; * and malformed origins are refused by both ParseCORSOrigins and api.NewRouter.
• Verification (repo root): make check — gofmt clean, go vet ./... clean, go test ./... all 8 packages OK (cmd/soroforge, internal/api, internal/catalog, internal/config, internal/deploy, internal/readiness, internal/stellar, internal/store), re-run with -count=1. make lint reports golangci-lint not installed and exits 0.

[drips-wave]

@abercrombie04 Great news! 🎉 Based on an automated assessment of this PR, the linked Wave issue(s) no longer count against your application limits.

You can now already apply to more issues while waiting for a review of this PR. Keep up the great work! 🚀

Learn more about application limits