CORS config not generated from APIProduct definition

[kcbabo]

Describe the bug Users should be able to specify CORS settings on an Environment or an API Product, but it appears as though CORS configuration only works on the Environment level. Specifying CORS configuration only at the APIProduct level does not produce CORS options to end clients invoking the API through a developer portal.

This appears to be due to the fact that CORS policy applied at the Environment level goes into the top-level Virtual Host options for an HTTP listener: https://github.com/kcbabo/portal-examples/blob/main/cors/etc/proxy-with-apienv.yaml#L30 While CORS policy applied at the Product level goes into the route configuration: https://github.com/kcbabo/portal-examples/blob/main/cors/etc/proxy-with-apiproduct.yaml#L48

To Reproduce Steps to reproduce the behavior:

1. Deploy petstore app
2. Deploy example portal environment with CORS defined at Environment level
3. Go to dev portal (petstore.example.com:31500) and submit a GET to the api/pets resource. API returns a 401 which means CORS check passed.
4. Delete example from step 2.
5. Deploy example portal environment with CORS defined at Product level
6. Repeat step 3. API returns a CORS error.

Expected behavior Specifying CORS configuration in only the APIProduct definition should be sufficient. In an environment where multiple teams are delivering API products into a single Environment, it is desirable for the CORS config for each API to be scoped only to that API and not shared across all APIs in the Environment.

Additional context Add any other context about the problem here, e.g.

• Gloo Portal version : 1.2.0-beta5
• Gloo Edge 1.10.1

[bewebi]

I've investigated a bit and I suspect the bug is on the Edge side.

Notably the CORS config is identical in the VirtualService produced by Portal regardless of whether it falls under a VirtualHost or a Route, corresponding to specifying at Environment or API Product level respectively

However the Proxy that results does have a difference: when CORS is specified on Routes, the AllowCredentials field is missing on the Proxy, while it is propagated correctly when specified on VirtualHosts.

I suspect, though haven't confirmed, that this is the key difference leading to the buggy behavior in Portal. I am still working on finding the offending code.

[spunuru]

Based on my initial testing, I can not reproduce the issue in Gloo Portal version : 1.2.0-beta8. I will need to do more testing to confirm.

[soloio-bot]

Zendesk ticket #485 has been linked to this issue.

[bewebi]

After further investigation, there does not appear to be a bug at all

The issue appears to be that the allowCredentials field is not set in the CORS options set on the API Product level in the example given on the issue When that field is set, the behavior is correct, matching the behavior observed when the example assets with CORS set on the Environment are applied

This would also explain why @spunuru was not able to reproduce on Sunday

The relevant documentation is a little buried, but the description for RouteSpec.Ooptions includes:

If cors is set, the default config provided by Gloo Portal on the VirtualService or VirtualHost will be overridden for this route. It will be up to the user to make sure CORS is configured correctly to work with the “Try it out” feature in the Developer Portal UI.