Enable CORS when importing an OpenAPI

[nmasse-itix]

Hello everybody! 🎩

When I'm importing my OpenAPI Specification file, the service is created in 3scale (👍) without any cors policy in the policy chain 👎.

As a result, my API is not working in the API Developer Portal 👎.

We could remediate this in at least two different ways 💪:

1. add an option to the 3scale import openapi command to enable the CORS policy (ie. --cors=enabled --cors-allow-header=X-Foo ...

-- OR --

2. add a command to manipulate the policy chain. Something like this:

3scale policy-chain export -d 3scale-instance -t my_api > policy_chain.json
jq 'something' policy_chain.json > new_policy_chain.json
3scale policy-chain import -d 3scale-instance -t my_api < new_policy_chain.json

or like this:

3scale policy-chain insert --at=first -d 3scale-instance -t my_api <<EOF
{
    "configuration": {
        "allow_headers": [
            "X-Foo"
        ],
        "allow_credentials": true,
        "allow_methods": [
            "GET",
            "POST"
        ]
    },
    "name": "cors",
    "version": "builtin",
    "enabled": true
}
EOF

with: --at= that could be first, last or a number.

The first one has the advantage of being easy to use for the customer (+) but may need five more options to the import openapi command (-).

The later one has the advantage to be powerful (+) but being idempotent is harder (-).

Note: currently, I'm enabling CORS globally on all services at the gateway level.

Any idea ?

[eguzki]

Hi,

First of all, thanks for this heads up @nmasse-itix . Indeed, this seems to be something very needed to be added ASAP.

I understand both approaches. I am not against them. I even like specially the first one. But I would like to propose a third one. It is, basically, providing that information in the openapi resource. AFAIK OpenAPI (2.0 or 3.0) does not support explicit support for CORS (which surprises me). There must be a good reason not to do that. I did not find it. Anyway, I am proposing to have some convention (provided by documentation) to provide the following information in the openapi resource. a) CORS wants to be enabled or not b) CORS configuration

Access-Control-Allow-Origin: https://foo.example
Access-Control-Allow-Methods: POST, GET, OPTIONS
Access-Control-Allow-Headers: X-PINGOTHER, Content-Type

Openapi allows Specification Extensions we could leverage to provide all this information.

Another consideration is the scope of the CORS policy. You mentioned a way to enable CORS globally for all services at a provider account level. As for your proposals, they were scoped at service level, i.e same CORS policy for all mapping rules. I do not want to lose the opportunity to bring the idea of, why not at HTTP resource level? Does it even 3scale support it? (@eloycoto is it possible at the gateway?). I think some customer may need specific CORS configuration at HTTP resource. This is what 3scale partially does when defining a mapping rule. It defines: this HTTP resource only allows a given HTTP method.

If you like the approach, we can start defining how should be CORS specified in the openapi resource and which scope it should have.

Let me mention @thomasmaas and @miguelsorianod that could contribute to the discussion.