Feature Request: Support for Wildcard Subdomains in allowedDevOrigins

[bl3ck]

Goals

1. Enable Next.js's Fast Refresh (HMR) for applications running in cloud development environments like Google Cloud Workstations, Gitpod, or Codespaces.
2. Allow developers to use a single, maintainable configuration for allowedDevOrigins in next.config.js without manually updating a dynamic hostname.
3. Improve the developer experience for users who work with dynamic hostnames for their dev servers.

Non-Goals

1. This proposal does not aim to add full regular expression support to allowedDevOrigins. The focus is on a simple, specific wildcard (*) for subdomains.
2. It does not seek to alter the core security behavior for production builds or for hosts that are not part of the wildcard pattern.
3. This is not a proposal to change how the dev server listens on a host and port (e.g., -H 0.0.0.0). It is a separate configuration feature to address a distinct issue.

Background

When a Next.js application runs in a cloud development environment, its development server is often exposed via a unique, dynamically generated hostname. For example, a URL might look like https://3000-user-project-abcdefgh.cloudworkstations.dev.

Next.js's Fast Refresh uses a WebSocket connection to push code changes to the browser. The allowedDevOrigins security feature in next.config.js is designed to prevent malicious websites from connecting to a developer's local dev server. However, it only supports exact string matching, which makes it incompatible with dynamic subdomains.

Current alternatives require a manual workaround:

1. The developer must either not use allowedDevOrigins at all, which compromises security.
2. They must find a way to dynamically inject the current hostname into next.config.js via an environment variable, which is often a brittle or complex process.

This feature is needed to provide a robust, maintainable, and secure solution for a growing number of developers using these popular cloud-based workflows.

Proposal

I propose adding support for a leading wildcard * to the allowedDevOrigins array. The implementation should allow for a pattern like *.cloudworkstations.dev to match any subdomain of that origin.

The implementation would involve:

1. Parsing a new type of entry in the allowedDevOrigins array. If an entry begins with *., it should be treated as a wildcard domain.
2. Implementing a Domain Suffix Matcher in the dev server's CORS and HMR WebSocket validation logic. Instead of a simple == comparison, the logic would check if the incoming request's Origin header ends with the configured wildcard pattern. For example, if the config is *.cloudworkstations.dev, the incoming origin 3000-eugen-workstation.cluster-asy4c5b3qjanivfwib4uufkjo2.cloudworkstations.dev would be a valid match.
3. Adding a validation check to ensure the wildcard can only be used at the beginning of the domain (e.g., *.*.vercel.app would be invalid, but *.vercel.app would be valid).

This feature would provide the perfect balance of security and usability for developers in modern cloud environments. I am interested in contributing to this feature and am ready to start the implementation process.