Skip to content

Auto-Inject "Access-Control-Allow-Credentials" for Private Port Responses #6687

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
AaronBeaudoin opened this issue Nov 12, 2021 · 6 comments
Labels
component: ws-proxy feature: ports meta: never-stale This issue can never become stale team: workspace Issue belongs to the Workspace team

Comments

@AaronBeaudoin
Copy link

AaronBeaudoin commented Nov 12, 2021

Problem

To accept CORS requests on services running behind private ports, developers currently have to configure the service to accept credentials, even though they aren't actually using them. This is because Gitpod requires credentials to be sent, but when the response comes back from the service it will be rejected if it doesn't have the Access-Control-Allow-Credentials header.

Desired Behavior

For responses coming from private ports, Gitpod should automatically add the Access-Control-Allow-Credentials header, because it is Gitpod that is actually using the credentials, not the service behind the port. This makes private port usage more transparent. (A bonus would be to actually document what Gitpod is requiring in the requests to private ports, so people don't have to dig down the forums rabbit hole like I did in order to find out. EDIT: I just made gitpod-io/website#2164 for this.)

Alternatives

Force the developer (like how it works currently) to configure all services that need to support CORS through private ports to accept credentials and add the Access-Control-Allow-Credentials header on responses, even though they aren't actually using doing anything with the incoming credentials.

Context

https://community.gitpod.io/t/why-do-i-get-a-cors-error-but-only-if-my-port-is-private/5547

Thanks to geropl for explaining this undocumented behavior and suggesting this solution.

@geropl geropl added team: workspace Issue belongs to the Workspace team component: ws-proxy labels Nov 15, 2021
@geropl
Copy link
Member

geropl commented Nov 15, 2021

This is sth I'd like to discuss with workspace: As explained here, we private ports in particular do behave special when it comes to credentials (required for us to authorize) and CORS (sth we could help out with, see @AaronBeaudoin explanation).

It's a tradeoff between "educating users" (adding doc) and "introducing magic", and I must admit I'm not 100% sure which to prefer. 🙂

@stale
Copy link

stale bot commented Feb 16, 2022

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@stale stale bot added the meta: stale This issue/PR is stale and will be closed soon label Feb 16, 2022
@stale stale bot closed this as completed Feb 27, 2022
@loujaybee loujaybee added feature: ports and removed meta: stale This issue/PR is stale and will be closed soon labels Apr 28, 2022
@loujaybee loujaybee reopened this Apr 28, 2022
@loujaybee
Copy link
Member

Potentially we could introduce this as an explicit option on the ports (either opt-in, or opt-out), whichever is the most sane default: https://www.gitpod.io/docs/references/gitpod-yml

@stale
Copy link

stale bot commented Sep 9, 2022

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@stale stale bot added the meta: stale This issue/PR is stale and will be closed soon label Sep 9, 2022
@stale stale bot closed this as completed Sep 25, 2022
@nVitius
Copy link
Contributor

nVitius commented Oct 11, 2022

@loujaybee @geropl
Can we re-open this issue?

Right now I'm having to conditionally enable Access-Control-Allow-Credentials if I detect that my app is running on gitpod. It would be nice if the proxy handled that for us.

@loujaybee loujaybee reopened this Oct 27, 2022
@stale stale bot removed the meta: stale This issue/PR is stale and will be closed soon label Oct 27, 2022
@loujaybee loujaybee added meta: stale This issue/PR is stale and will be closed soon meta: never-stale This issue can never become stale labels Oct 27, 2022
@stale stale bot removed the meta: stale This issue/PR is stale and will be closed soon label Oct 27, 2022
@Methodician
Copy link

@nVitius can you show an example of this approach? It seems that workarounds are all we have still.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
component: ws-proxy feature: ports meta: never-stale This issue can never become stale team: workspace Issue belongs to the Workspace team
Projects
None yet
Development

No branches or pull requests

5 participants