Standardize CORS support for provider gateway APIs used by browser deployments

[NiKrause]

Browser-based Akash deployment clients need to call provider gateway APIs directly after the wallet transactions succeed, especially to upload manifests and read lease status. Today some providers reject browser CORS preflights, which makes browser-only deployments fail after the lease has already been created.

This is being filed in akash-network/support because akash-network/provider appears to have GitHub Issues disabled. The fix likely belongs in the provider gateway implementation.

Example failure from a local PWA:

Access to fetch at
https://provider.m3a.eu-n-3.digitalfrontier.network:8443/deployment/27495397/manifest
from origin http://localhost:5173 has been blocked by CORS policy:
Response to preflight request doesn't pass access control check:
No 'Access-Control-Allow-Origin' header is present on the requested resource.

Manual preflight against that provider confirms the issue:

curl -k -i -X OPTIONS \
  'https://provider.m3a.eu-n-3.digitalfrontier.network:8443/deployment/27495397/manifest' \
  -H 'Origin: http://localhost:5173' \
  -H 'Access-Control-Request-Method: PUT' \
  -H 'Access-Control-Request-Headers: authorization,content-type'

Response:

HTTP/1.1 405 Method Not Allowed

No CORS headers are returned.

This cannot be fixed in the JavaScript SDK alone. The browser blocks the request before JavaScript can read the response. The provider gateway needs to answer the preflight with CORS headers.

Where this appears in provider

The manifest upload route is registered here:

https://github.com/akash-network/provider/blob/afc4dd7c30a2ba3bb79d471e6dc5fa6ee14018ff/gateway/rest/router.go#L142-L151

mrouter.HandleFunc("/manifest",
    createManifestHandler(log, pclient.Manifest())).
    Methods(http.MethodPut)

The gateway middleware in server.go injects provider/cluster context but does not add CORS headers:

https://github.com/akash-network/provider/blob/afc4dd7c30a2ba3bb79d471e6dc5fa6ee14018ff/gateway/rest/server.go#L30-L55

The auth middleware runs globally in the router:

https://github.com/akash-network/provider/blob/afc4dd7c30a2ba3bb79d471e6dc5fa6ee14018ff/gateway/rest/router.go#L104

So CORS should probably be handled before auth/route-specific method handling, or OPTIONS routes should be explicitly registered. Preflight requests should not require JWT or mTLS; the actual PUT / GET requests must remain protected exactly as they are today.

Why CORS is needed

Browser clients need at least these provider gateway calls:

• PUT /deployment/{dseq}/manifest
• GET /lease/{dseq}/{gseq}/{oseq}/status
• likely also GET /lease/{dseq}/{gseq}/{oseq}/manifest
• optionally logs/events/shell endpoints if browser clients support them later

These calls use JWT bearer auth or certificate auth semantics. CORS does not replace provider authorization and does not make unauthenticated access valid. It only allows browsers to send the already-authorized request.

Without provider-side CORS, browser clients must fall back to a CLI or server-side proxy, which breaks the wallet-only/browser-only deployment flow.

Suggested behavior

Provider gateway should respond to preflight requests with something like:

HTTP/1.1 204 No Content
Access-Control-Allow-Origin: *
Access-Control-Allow-Methods: GET, PUT, POST, OPTIONS
Access-Control-Allow-Headers: Authorization, Content-Type
Access-Control-Max-Age: 600
Vary: Origin

Or, if wildcard origin is not desired, make allowed origins configurable while still providing a default that works for browser Akash clients.

Actual protected requests should include:

Access-Control-Allow-Origin: *
Vary: Origin

and continue enforcing existing JWT/mTLS permission checks.

Acceptance criteria

• Browser preflight succeeds for PUT /deployment/{dseq}/manifest.
• Browser preflight succeeds for authenticated lease status/manifest endpoints.
• Existing JWT/mTLS authorization behavior is unchanged for non-OPTIONS requests.
• Integration tests cover OPTIONS preflight with:
  • Origin
  • Access-Control-Request-Method
  • Access-Control-Request-Headers: authorization,content-type
• Provider operators get standardized behavior instead of each provider needing custom reverse-proxy CORS config.

Notes

Related Akash Console work exists for CORS problems on chain/RPC endpoints, but this issue is specifically about provider gateway endpoints. For example:

• fix(network): use curated node lists for CORS-compatible endpoints console#3046
• fix(network): silence false-positive "Blockchain unavailable" banner console-air#21
• fix(stats): proxy blockchain health check to avoid CORS error console#3003

[NiKrause]

Small clarification after comparing Console Air:

Console Air avoids this direct browser CORS failure by routing provider API calls through its same-origin Next API route and the Akash provider proxy (/api/provider-proxy/{network} -> https://console.akash.network/provider-proxy-%{NETWORK}). So the browser does not preflight the provider gateway directly.

That proxy path is useful, but this issue still applies to pure browser/PWA clients that call provider gateways directly. Those clients still need standardized provider-side CORS, or they must depend on a server-side/provider proxy fallback.