Substrate: Separate rpc-cors into WS/HTTP options

[joepetrowski]

A single CLI option specifies allowed origins for both HTTP and WS requests.

--rpc-cors <ORIGINS>
            Specify browser Origins allowed to access the HTTP & WS RPC servers.

            A comma-separated list of origins (protocol://domain or special `null` value). Value of `all` will disable
            origin validation. Default is to allow localhost and https://polkadot.js.org origins. When running in --dev
            mode the default is to allow all origins.

Users should be able to select HTTP and WS origins individually, e.g.

--rpc-all-cors <ORIGINS>
            Specify browser Origins allowed to access the HTTP & WS RPC servers.
            Overrides --rpc-http-cors and --rpc-ws-cors.

--rpc-http-cors <ORIGINS>
            Specify browser Origins allowed to access the HTTP RPC servers.

--rpc-ws-cors <ORIGINS>
            Specify browser Origins allowed to access the WS RPC servers.

CC @chevdor

[bkchr]

Why? What is the use case of differentiating between them?

[chevdor]

In terms of security, you may want to allow CORS for WebSocket but not for HTTP or at least independently.

I would not bother with a --rpc-all-cors flag but splitting ws et http would also allow users to have different origins for ws and for http.

[bkchr]

The only difference between HTTP and Websocket is that Websocket supports long lived connections, aka subscriptions. I really don't see the use case of splitting them. What is the advantage?

[tomusdrw]

I'm also to be convinced what's the actual use case is to justify the maintenance and extending the content of --help.

[yangwao]

For example, when I want to run the local node with @vue-polkadot with just --rpc-ws-cors for various operation, but do not allow rpc at all.

For various deployments could be a thing and for some cases, we don't need to allow --rpc-http-cors

[tomusdrw]

Sounds that you actually want to disable http transport instead of just limiting cors, no? Perhaps that would be an option worth including?

[yangwao]

@tomusdrw yes, it adds another scenario I've realized.

[bkchr]

I still don't see the reason why you want to disable http. Someone could still do the same operations using ws.

Given that there was no real explanation on what this would bring and that we already have too many CLI options, I will close this. If someone comes up with a real use case, explanation why we need this, we can reopen the issue.