Skip to content
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

Use the remoteHostHeader option when looking up websocket address #2107

Open
marcusball opened this issue Oct 19, 2024 · 1 comment
Open
Assignees
Labels
feature-request Request for new features or functionality

Comments

@marcusball
Copy link

Issue

My issue is similar to the one described in #778. I am trying to run and debug a Node server which sits behind a reverse proxy. At the time of the aforementioned issue, the debugger always set the host to localhost regardless of the configured address, which made it impossible to a debugger server behind a reverse proxy. The remoteHostHeader option was added in #1664 which fixed most of that problem, allowing for a custom Host header when connecting to the websocket of the debug server.

My issue is that config option only applies to the websocket connection, but when vscode begins debugging and it tries to find the websocket url, it still forces the host header to be localhost.

What this means is that I can not connect to the debugger by having VS Code discover the websocket url. Here's an example of that configuration:

{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "Debug: nestjs docker container",
            "type": "node",
            "request": "attach",
            "restart": true,
            "port": 9229,
            "address": "exampleservice.mydomain.test",
            "remoteHostHeader": "exampleservice.mydomain.test",
            "localRoot": "${workspaceFolder}",
            "remoteRoot": "/usr/src/app",
        }
    ]
}

And this is the request sent when code tries to discover the websocket:

# ncat -l 0.0.0.0 9229
GET /json/list HTTP/1.1
user-agent: got (https://github.com/sindresorhus/got)
accept: application/json
host: localhost
accept-encoding: gzip, deflate, br
Connection: close

Code, however, can successfully connect to the debug server if you manually specify the websocket address, as in this example:

{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "Debug: nestjs docker container",
            "type": "node",
            "request": "attach",
            "restart": true,
            "port": 9229,
            "address": "exampleservice.mydomain.test",
            "remoteHostHeader": "exampleservice.mydomain.test",
            "websocketAddress": "ws://exampleservice.mydomain.test:9229/c8884625-d3bd-4a8a-b91f-2380bd2bb1b6",
            "localRoot": "${workspaceFolder}",
            "remoteRoot": "/usr/src/app",
        }
    ]
}

The problem there is that is very inconvenient since the websocket address changes every time the server is restarted, so this isn't a really maintainable solution.

Proposed feature

The simplest solution is to update the calls to fetchJsonWithLocalhostFallback to pass in the remoteHostHeader config value, and allow it to override localhost in the same fashion as the websocket connection.

I can't really imagine that would cause any issues or regressions unless someone managed to create a convoluted set up that discovers over localhost but connects via a reverse proxy.


If this seems like a reasonable request, I'd be willing to try to get it implemented and open a PR for it, but I'd want to get a general OK and iron out any potential concerns before I'd attempt to do so.

@marcusball marcusball added the feature-request Request for new features or functionality label Oct 19, 2024
@connor4312
Copy link
Member

I would take a PR to fix this. FYI you probably will need to rewrite the host header in your reverse proxy because, as a security precaution, Node blocks (or at least blocked, 84a429b) inspector requests that contain non-local Host headers.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature-request Request for new features or functionality
Projects
None yet
Development

No branches or pull requests

2 participants