Allow for defining server.allowedHosts through environment variables

[CompuIves]

Description

Recently a security improvement was introduced to Vite, where Vite now checks if the domain in the Host header is configured in server.allowedHosts if it is not localhost.

This breaks some CodeSandbox examples, because while Vite is listening on localhost:5173, users access the server through https://:id-5173.csb.app on CodeSandbox. With newer versions of Vite, this returns a 403. Currently, we recommend people to add .csb.app to their server.allowedHosts, but it would be nice if we also have a way to make this work with no configuration.

Suggested solution

I was thinking we could potentially solve this in two ways, and I'm curious what you're thinking of the possible solutions:

1. We could hard-code, similar to localhost, that .csb.app is allowed in server.allowedHosts, or:
2. We could add support for defining hosts in server.allowedHosts by passing in environment variables. On the CodeSandbox side, we could introduce a default environment variable in all VMs (like VITE_ALLOWED_HOST=.csb.app), which would then also be used by Vite for its checks.

I'm a big fan of Vite, I would love to contribute something like this if this makes sense to you!

Alternative

No response

Additional context

No response

Validations

• Follow our Code of Conduct
• Read the Contributing Guidelines.
• Read the docs.
• Check that there isn't already an issue that request the same feature to avoid creating a duplicate.

[sapphi-red]

Sorry for the breakage. I think adding the env var makes sense to me. Do you know if there's any similar env var names? I think it would be good to align with them.

I'm a big fan of Vite, I would love to contribute something like this if this makes sense to you!

Awesome 💚

[dominikg]

if we go with an env variable, i think it would have to be accompanied by a check that it does not start with envPrefix https://vite.dev/config/shared-options.html#envprefix or at least we would have to pick one thats highly unlikely to be used in the wild, eg __VITE_DEV_ORIGIN

I wonder if there is a way for codesandbox to avoid the cross origin setup here or use existing means to configure the dev server eg hook the vite dev call and change it to vite dev --hostname xxxx --port yyyy

[CompuIves]

Do you know if there's any similar env var names?

A long long time ago, create-react-app used to check the HOST environment variable to determine which domains are valid. This was to support Cloud9(!) I'm not sure if we want something that generic as a name, though. Django has a setting called ALLOWED_HOSTS, but it does not support setting it as an env var as far as I know. Something more internal like __VITE_DEV_ORIGIN would also work.

I wonder if there is a way for codesandbox to avoid the cross origin setup here or use existing means to configure the dev server eg hook the vite dev call and change it to vite dev --hostname xxxx --port yyyy

There is a way... if we manually let the proxy forward header Host: localhost when proxying a request instead of Host: :id-5173.csb.app. We used to do that initially, but it broke some other sandboxes. For example, Bun uses the Host header to determine its injected URLs when serving html (so the static assets would link to localhost, but they should instead link to :id-3000.csb.app).

One thing I could try... is to only forward Host: localhost if the port is 5173, but it would be an imperfect solution.

Overriding the binary is a bit more tricky, because when people fork a sandbox it is live cloned, so the running Vite process is cloned as well, it will continue running inside the child. But the hostname did change, so then we'd have to restart Vite with the new --hostname.

So we could also transparently fix it on our side by changing the proxy, but the environment variable feels a bit cleaner. It depends on what you're most comfortable with in terms of implementation.

[dominikg]

if there is a less hacky way for you to detect when to change the proxy and when not (what happens if someone were to use bun+vite?) i think i'd prefer that over adding a way to configure vite via environment variables.

That could set a dangerous precedent and we have to answer a lot of questions like which value wins if both are set, what happens if the env value changes and the dev server is still running, will it pick up the new value when there is an automatic restart? Do we have to watch that value?

[dominikg]

if you are able to add a vite-plugin-codesandbox you could also ensure the configuration with a config hook (and possibly read from env in that without requiring vite to do it internally).

[sapphi-red]

A long long time ago, create-react-app used to check the HOST environment variable to determine which domains are valid. This was to support Cloud9(!) I'm not sure if we want something that generic as a name, though. Django has a setting called ALLOWED_HOSTS, but it does not support setting it as an env var as far as I know. Something more internal like __VITE_DEV_ORIGIN would also work.

Yeah, HOST feels too generic. I think __VITE_ALLOW_HOST would be good. This will align with our option name.

if you are able to add a vite-plugin-codesandbox you could also ensure the configuration with a config hook (and possibly read from env in that without requiring vite to do it internally).

I think that's difficult to do for all the Vite-based frameworks that does not use vite.config.js. I feel patching the behavior on the runtime side makes the behavior confusing.

[sapphi-red]

I discussed with the team about the name and we think the env var named __VITE_ADDITIONAL_SERVER_ALLOWED_HOSTS would be good.

[CompuIves]

Thanks a lot for the quick response! The solution makes sense to me, I will open a PR with __VITE_ADDITIONAL_SERVER_ALLOWED_HOSTS.