[proxy] Remove ineffectual cors on /api/* and /headless-log-download*

[easyCZ]

Description

See context

Because the configuration results in AllowedOrigins = ["*.<domain>"], it doesn't actually match anything because the AllowedOrigins must contain a URL (ie. https://*.gitpod.io), rather than just the host.

To prove the existing configuration does not work as intended, do the following requests:

curl https://gitpod.io/api/foo-bar \
   -H "Origin: https://api.gitpod.io/" \
   -H "Access-Control-Request-Method: POST" \
   -H "Access-Control-Request-Headers: X-Requested-With" \
   -X OPTIONS \
   -v

 HTTP/2 204
< access-control-allow-credentials: true
< access-control-allow-headers: X-Requested-With
< access-control-allow-methods: POST
< access-control-allow-origin: https://api.gitpod.io/
< access-control-max-age: 60
< content-security-policy: frame-ancestors 'self' https://*.gitpod.io https://gitpod.io/
< referrer-policy: no-referrer-when-downgrade
< strict-transport-security: max-age=31536000
< vary: Origin
< vary: Access-Control-Request-Method
< vary: Access-Control-Request-Headers
< x-content-type-options: nosniff
< x-xss-protection: 1; mode=block
< date: Tue, 11 Oct 2022 06:53:14 GMT
< via: 1.1 google
< alt-svc: h3=":443"; ma=2592000,h3-29=":443"; ma=2592000


curl https://gitpod.io/api/foo-bar \
   -H "Origin: https://gitpod.io/" \
   -H "Access-Control-Request-Method: POST" \
   -H "Access-Control-Request-Headers: X-Requested-With" \
   -X OPTIONS -v

 HTTP/2 204
< content-security-policy: frame-ancestors 'self' https://*.gitpod.io https://gitpod.io/
< referrer-policy: no-referrer-when-downgrade
< strict-transport-security: max-age=31536000
< vary: Origin
< vary: Access-Control-Request-Method
< vary: Access-Control-Request-Headers
< x-content-type-options: nosniff
< x-xss-protection: 1; mode=block
< date: Tue, 11 Oct 2022 06:54:42 GMT
< via: 1.1 google
< alt-svc: h3=":443"; ma=2592000,h3-29=":443"; ma=2592000

Neither of these contain the required Access-Control-Allow-* headers on the responses.

Related Issue(s)

Fixes #

How to test

Release Notes

NONE

Documentation

Werft options:

• /werft with-local-preview
  If enabled this will build install/preview
• /werft with-preview
• /werft with-integration-tests=all
  Valid options are all, workspace, webapp, ide

[werft-gitpod-dev-com]

started the job as gitpod-build-mp-proxy-api-cors.1 because the annotations in the pull request description changed
(with .werft/ from main)

[geropl]

/hold

@easyCZ Can we wait with this PR until I had a chance to review, please?

The segment of the API is a "cargo cult" artifact IIRC. But still I'd like to understand better why it's there before we remove it - even it turns out to be superfluous as you said. 👍

[easyCZ]

/hold

@easyCZ Can we wait with this PR until I had a chance to review, please?

The segment of the API is a "cargo cult" artifact IIRC. But still I'd like to understand better why it's there before we remove it - even it turns out to be superfluous as you said. 👍

Sure, no problem. Check out the linked context for demonstration that the definition actually does not take any effect.

[easyCZ]

@geropl PTAL when you get a chance.

[geropl]

@easyCZ to me it looks like as we're still using and relying on it. This example is for the workspace auth cookie:

Also, the fact that we don't see it on every request does not prove it's not effective (compare the allowedHeaders = []string{"Accept", "Authorization", "Cache-Control", "Content-Type", "DNT", "Keep-Alive", "Origin", "User-Agent",
"If-Match", "If-Modified-Since", "If-None-Match",
"X-Requested-With", "X-Account-Type", "X-Client-Commit", "X-Client-Name", "X-Client-Version", "X-Execution-Id", "X-Machine-Id", "X-Machine-Session-Id", "X-User-Session-Id",
}).

When looking at your example in the description:

Neither of these contain the required Access-Control-Allow-* headers on the responses.

The first response contains them, no?

< access-control-allow-credentials: true
< access-control-allow-headers: X-Requested-With
< access-control-allow-methods: POST
< access-control-allow-origin: https://api.gitpod.io/
< access-control-max-age: 60

Still could be missing sth though. 🤔

[easyCZ]

The first response contains them, no?

It does. Not sure how I missed this. Will run through this again to validate. Thanks for investigating.

[geropl]

I'm starting a workspace on this preview env now to test if it just works 😬

[geropl]

Ok, at least Firefox does not want to:

Note that this behavior might very well be different between clients! E.g. Chrome behaved differently when I was last testing CORS behavior Jan. 2020 😬