starred/headscale
1
0
Fork 0
mirror of https://github.com/juanfont/headscale.git synced 2026-01-13 12:50:32 +01:00
Code Issues 98 Packages Projects Releases 10 Wiki Activity

[Feature] Enable CORS inside Headscale. #888

New Issue
Closed
opened 2025-12-29 02:25:17 +01:00 by adam · 2 comments
adam commented 2025-12-29 02:25:17 +01:00
Owner
Copy Link

Originally created by @Jisse-Meruma on GitHub (Dec 16, 2024).

Use case

Feature Overview: Injecting Access-Control-Allow-Origin Response Header

This feature aims to inject the Access-Control-Allow-Origin response header directly through the configuration file (config.yaml). The primary purpose of this feature is to simplify the setup process for those using Headscale with a Web Tailscale Client.

Learn more about the Tailscale SSH Console

Justification

  1. Simplified Setup for Tailscale Web Client:

    • Tailscale uses a browser client to set up an SSH console.
    • My company Leaning Technologies uses a Tailscale web client to establish peer-to-peer connections between two browsers.
    • We use Headscale for companies that prefer not to use the Tailscale Control Plane

  2. Eliminating the Proxy Layer:

    • Before: Users needed to deploy and configure an additional proxy server behind the Headscale server to manage Cross-Origin Resource Sharing (CORS).
    • After: This feature allows users to directly configure CORS support through the config.yaml file, eliminating the need for an extra proxy layer.

  3. Following the Same Principle:

    • Headscale also supports integrated TLS, This is also to eliminate the use of a proxy server. This feature extends that Idea to also let you enable CORS

  4. Quality of Life Improvement:

    • The ability to enable CORS through the configuration file simplifies deployment and configuration, making it more user-friendly and reducing setup complexity.

Configuration Details

The Access-Control-Allow-Origin header can be configured by adding the following to the config.yaml file:

  # Examples:
  # "*" - Allow access from any origin (use with caution).
  # "http://example.com" - Allow access only from the specified origin.
  # "" - Disable CORS, no cross-origin requests allowed.
  Access-Control-Allow-Origin: "*" # Allows all origins

Description

Feature Overview: Injecting Access-Control-Allow-Origin Response Header

This feature allows the injection of the Access-Control-Allow-Origin response header directly through the config.yaml file. The primary purpose is to simplify the setup process for users of Headscale with a Web Tailscale Client, making it easier to handle Cross-Origin Resource Sharing (CORS) without needing to set up a proxy server.

Configuration Details

The Access-Control-Allow-Origin header can be configured by adding the following to the config.yaml file:

Contribution

  • I can write the design doc for this feature
  • I can contribute this feature

How can it be implemented?

  1. Add an new option to the config.yaml file.
  2. Check if the Option has been set.
  3. Add a new header in all response messages
Originally created by @Jisse-Meruma on GitHub (Dec 16, 2024). ### Use case ### Feature Overview: Injecting `Access-Control-Allow-Origin` Response Header This feature aims to inject the `Access-Control-Allow-Origin` response header directly through the configuration file (`config.yaml`). The primary purpose of this feature is to simplify the setup process for those using Headscale with a Web Tailscale Client. [Learn more about the Tailscale SSH Console](https://tailscale.com/blog/ssh-console) #### Justification 1. **Simplified Setup for Tailscale Web Client**: - Tailscale uses a browser client to set up an SSH console. - My company Leaning Technologies uses a Tailscale web client to establish peer-to-peer connections between two browsers. - We use Headscale for companies that prefer not to use the Tailscale Control Plane 2. **Eliminating the Proxy Layer**: - **Before**: Users needed to deploy and configure an additional proxy server behind the Headscale server to manage Cross-Origin Resource Sharing (CORS). - **After**: This feature allows users to directly configure CORS support through the `config.yaml` file, eliminating the need for an extra proxy layer. 3. **Following the Same Principle**: - Headscale also supports integrated TLS, This is also to eliminate the use of a proxy server. This feature extends that Idea to also let you enable CORS 4. **Quality of Life Improvement**: - The ability to enable CORS through the configuration file simplifies deployment and configuration, making it more user-friendly and reducing setup complexity. #### Configuration Details The `Access-Control-Allow-Origin` header can be configured by adding the following to the `config.yaml` file: ```yaml # Examples: # "*" - Allow access from any origin (use with caution). # "http://example.com" - Allow access only from the specified origin. # "" - Disable CORS, no cross-origin requests allowed. Access-Control-Allow-Origin: "*" # Allows all origins ``` ### Description ### Feature Overview: Injecting `Access-Control-Allow-Origin` Response Header This feature allows the injection of the `Access-Control-Allow-Origin` response header directly through the `config.yaml` file. The primary purpose is to simplify the setup process for users of Headscale with a Web Tailscale Client, making it easier to handle Cross-Origin Resource Sharing (CORS) without needing to set up a proxy server. #### Configuration Details The `Access-Control-Allow-Origin` header can be configured by adding the following to the `config.yaml` file: ### Contribution - [X] I can write the design doc for this feature - [X] I can contribute this feature ### How can it be implemented? 1. Add an new option to the config.yaml file. 2. Check if the Option has been set. 3. Add a new header in all response messages
adam added the enhancementstale labels 2025-12-29 02:25:17 +01:00
adam closed this issue 2025-12-29 02:25:17 +01:00
adam commented 2025-12-29 02:25:17 +01:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (Mar 17, 2025):

This issue is stale because it has been open for 90 days with no activity.

@github-actions[bot] commented on GitHub (Mar 17, 2025): This issue is stale because it has been open for 90 days with no activity.
adam commented 2025-12-29 02:25:18 +01:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (Mar 24, 2025):

This issue was closed because it has been inactive for 14 days since being marked as stale.

@github-actions[bot] commented on GitHub (Mar 24, 2025): This issue was closed because it has been inactive for 14 days since being marked as stale.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
CLI
DERP
DNS
Nix
OIDC
SSH
bug
database
documentation
duplicate
enhancement
faq
good first issue
grants
help wanted
might-come
needs design doc
needs investigation
no-stale-bot
out of scope
performance
policy 📝
pull-request
Mirrored from GitHub Pull Request
 question
regression
routes
stale
tags
tailscale-feature-gap
well described ❤️
wontfix
No Label enhancement stale
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
adam
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/headscale#888
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?