Enable CORS options by default

[aaroncox]

We just ran into what we considered to be a mundane API client fix on the wharfkit/antelope library, but it turns out to break functionality with a large portion of API providers out in the wild.

We added Content-Type: application/json to all of our HTTP POST request. Browsers, following this standard, issue either a OPTIONS request alongside of this - which most API providers automatically route to nodeos. The nodeos APIs don't respond to this request with the default config, and so the API request is terminated.

To start moving in a direction where the client SDKs can start using the appropriate content types, I'd propose we set the defaults on these parameters to be open, instead of specifying them:

• access-control-allow-origin default to *
• access-control-allow-headers default to * (or a standard CORS subset)

If operators would prefer to have more strict settings, they can then use the config file to override them.

Leap 6 being a hardfork and requiring all nodes to update would be an ideal time for this. It would allow us to fix the library after the release of this next version, without breaking the applications or requiring all API operators to update their nodeos/nginx/etc configurations.

[apporc]

another option, http-validate-host, it requires the listening address to be the same as Host headers used in request, which is too strict for a local development node, and not necessary in normal deployment with nginx as reverse proxy. Maybe only useful in a deployment where nodeos is the top level endpoint.
Unless we allow set this allowed_host value in configuration, not imply using listening address, listening address is not necessarily the same as the request host. For example we can set nodeos to listen on 127.0.0.1:8080 and use nginx to proxy another [external ip] to it, then the request Host header is the external ip or some domain name, not 127.0.0.1, this will fail the validate.

[ericpassmore]

Does safari support * Wildcards? https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Access-Control-Allow-Headers

[aaroncox]

Judging by that page, I'd assume no - but honestly I haven't tested it. In our nginx configurations where we set CORS, we'll typically use the normal 3 that are required:

add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS' always;

Maybe we tailor that list specifically to the methods that Leap actually utilizes.

I guess speaking of which, does Leap respond to options requests appropriately with the CORS configuration? I've never directly used CORS via Leap, so I am not sure what the capabilities here are. We've always proxied with nginx.

[matthewdarwin]

We set CORS in nginx as well.