Headscale: Added an option to set an Access-Control-Allow-Origin resp…

[Jisse-Meruma]

add a header to enable Cross-Origin Resource Sharing (CORS) #2301

• have read the CONTRIBUTING.md file
• raised a GitHub issue or discussed it on the projects chat beforehand
• added unit tests
• added integration tests
• updated documentation if needed
• updated CHANGELOG.md

[kradalby]

I dont think this is the place for this documentation, and we have our own documentation. This looks like internal notes.

[Jisse-Meruma]

You are correct this has been reverted

[kradalby]

This does not follow the format of the config file and has not been discussed. This isnt really anything we need and people needing this can handle it in Nginx and the likes.

[Jisse-Meruma]

@kradalby

I have modified the code to align with the requested configuration file format.

I did open an accompanying issue for discussion: #2301. I also see mentions of a project chat, could you point me to it?

The idea of this feature is to simplify the Headscale server setup and have everything in one place. Tailscale continues to grow in the browser sector; for example, they recently released their new SSH client.

Our company has just released WebVM 2.0, which is a virtual machine inside the browser. We use this product with Tailscale to establish fast peer-to-peer connections between machines.

With this small change, the Headscale setup for the browser would be much easier and much simpler, especially in combination with your integrated TLS support.

This feature has already been requested in two other issues but without success. Here are their references: #623 #1283 .

[routerino]

This does not follow the format of the config file and has not been discussed. This isnt really anything we need and people needing this can handle it in Nginx and the likes.

FYI expecting people to rely on a reverse proxy to intercept requests and inject CORS is introducing a large amount of user-side complexity that doesn't need to be there. I (as the maintainer of headscale ui) get people confused about this pretty much twice a month and opening issues as a result, even when the troubleshooting steps are listed (twice) on the front page readme.

A simple UI_DOMAIN configuration that optionally sets the appropriate CORS information would solve a lot of issues. I would not suggest allowing * anyway since browsers are planning to block that syntax.

[Jisse-Meruma]

A simple UI_DOMAIN configuration that optionally sets the appropriate CORS information would solve a lot of issues. I would not suggest allowing * anyway since browsers are planning to block that syntax.

We do want to keep the flexibility of using the * available, but if indeed browsers are planning to block this syntax, I will make sure to update the feature to check for this syntax. To avoid any confusion, I would prefer to stick with the normal CORS syntax. This * is indeed another security risk, but this flexibility is also possible by using a reverse proxy. However, if Headscale agrees to not allow *, then I would gladly make another commit with a fix.