Vscode-js-debug: Source-maps should work on pages with authentication

[digeff]

On v1 we had issues with sites with authentication, because the debug adapter didn't know the credentials, and it failed to retrieve the source-maps. We need to add some way of supporting this scenario to js-debug

[digeff]

@connor4312 Do you have an ETA of when you'll be able to get into this issue?

[connor4312]

The Chrome devtools get around this because they inherit the browser's context and authentication. We don't get that, and can't get that as a debugger.

One alternative which was brought up a couple months ago was using the browser's fetch or XHR to retrieve sourcemaps and then return them to js-debug. However, a core mechanism of js-debug is pausing on scripts to parse sourcemaps, which halts the event loop. While paused we do not receive any response to XHR or fetch requests--either as a promise/callback or as a CDP Network.responseReceived/Network.loadingFinished event--so this is a non-starter.

The only other avenue I see is allowing the caller to provide extra headers in the launch configuration. I'm thinking of something like the following, which I believe should be flexible enough to do everything callers will need:

/**
 * A simple key-value header appended to requests.
 */
export interface ILiteralHeader {
  key: string;
  value: string;
}

/**
 * An instruction to retrieve headers by running a VS Code command. This will
 * be resolved in the debug configuration provider prior to launch. The command
 * should return an array of AdvancedHeaders.
 */
export interface IHeaderByCommand {
  command: string;
  args?: unknown[];
}

/**
 * An instruction to retrieve headers by running a DAP method call on-demand.
 * The DAP command should reply with an array of AdvancedHeaders. Request
 * data will be provided as the "request" in the method call.
 */
export interface IHeaderByDap {
  method: string;
  params?: unknown;
}

export type AdvancedHeader = IHeaderByCommand | IHeaderByDap | ILiteralHeader;

So, for example, I could launch with basic authentication:

"requestHeaders": [
  { "key": "Authorization", "value": "Basic }
]

...or delegate to some extension that provides OAuth credentials

"requestHeaders": [
  { "command": "my-extension.getOAuthHeaders", "args": ["myAccount"] }
]

...if VS wants to build something in that provides Windows authentication at runtime, it might be something like

"requestHeaders": [
  { "method": "getWindowsAuthHeaders" }
]

The method option is designed for internal use and would not be exposed as autocompletable in the configuration contributions shown to users of VS Code.

[digeff]

Would it make sense to ask the CDP API team to add an API that lets us do this?
Can we listen to network requests, and extract the headers from there, so we don't need to ask the user to configure the headers?

[connor4312]

To an extent. For cookies, there's a CDP method that lets us retrieve cookies for a specific url. Applying that to outgoing requests should be easy and safe. There does not seem to be a similar API for headers, and I'm not sure how I want to deal with the authorization header. The most conservative approach would be to allow an authorization header we read on a domain to apply to requests going to the domain iff they're initiated by other resources on the domain. So a script example.com/script.js could have a sourcemap pointing to example.com/script.map.js and get headers, but contoso.com/script.js requesting that url would not receive the authorization header in its request. I will look into this further.

Or, we don't support arbitrary Authentication headers and only implement defined formats, like HTTP Basic auth, and follow their specifications for the scope in which we share headers.

The downside is that header sharing like this won't support authentication that requires authentication derived from the request, but the Chrome devtools would not either and I've never seen anyone requesting static resources behind that kind of authentication.

[roblourens]

Or it might be acceptable to fetch sourcemaps async in this case, and say that you have to reload the page to hit breakpoints in startup code, old school style? I imagine this is somewhat rare?

[connor4312]

In dd9cb8353fef396d07c280f1ea41a4b658799544 I have added support for cookie-based authentication. However, Windows Authentication will not work (either with cookies or the header-copying as suggested) as it requires repeated server negotiation. For example, in a hello world asp.net framework app with windows authentication, it takes two cycles of negotiation to get bootstrap.js.

I don't see a way for us to support this in our current model. Two other approaches:

• async fetch as Rob mentioned. We'd need some flag to indicate this is the mode we want to run in.
• map urls and indicate we want to retrieve them from disk instead.

Open to ideas.

[roblourens]

We'd need some flag to indicate this is the mode we want to run in.

I was thinking you could try to download the sourcemaps as usual, and if you get some permission denied error, then do the async fetch in the page (and maybe log a warning)

[klimowskict]

Just checking in on this issue, it is affecting my team. We use windows auth in all our apps not just for authentication itself but to also pull the user ID of the user and display it in the template, etc. Any updates on progress?

[klimowskict]

Hi all, checking in again, there have been a few updates. Is this any closer to being addressed?

[connor4312]

Not yet.

The feasible way this can be done is to install a webworker in the page and then execute sourcemaps fetches there.

[klimowskict]

A user on stack overflow recommended this workaround

https://stackoverflow.com/a/63158024/9974025

"I had similar problem, and found solution in this thread. Basically you have to replace the "webpack://" URLs with "file:///"

npm i @angular-builders/custom-webpack -D

Make sure you install the version matching your webpack.
create "custom-webpack.config.js" in your app root with following content:

var webpack = require('webpack');

const config = {
    plugins: [
        new webpack.SourceMapDevToolPlugin({
                moduleFilenameTemplate: 'file:///[absolute-resource-path]'
            })
       ]
    };

    module.exports = config;

And change the "builder" option in your angular.json:

...
    "build": {
      "builder": "@angular-builders/custom-webpack:browser",
      "options": {
        "customWebpackConfig": {
          "path": "./custom-webpack.config.js"
        },
...

Follow the links in that thread, there is more documentation. All credits to marczellm.
Hope this helps, it worked for me."

Is this something that can be implemented on your end or perhaps documented as a workaround?

[connor4312]

If you're using webpack, setting your devtool to inline-source-map should also be sufficient so that the sourcemap content are included as part of the scriptParsed event we get from the browser and we don't have to make a separate request for it.

[connor4312]

It looks like there's a new experimental API that we could use to request resources directly through devtools. This could allow the scenario to work.

[poke]

Hey, I just wanted to say that I am also affected by this limitation. I have a React app hosted inside an ASP.NET Core application that uses Windows authentication. The client-side app runs on a Node development server on port 3000 but the ASP.NET Core app runs on 5000 and contains a reverse proxy to forward requests to the Node development server (replicating how the app will be hosted in production).

When I try to debug the app on port 5000 (proxied with Windows authentication), breakpoints will not be hit and there are some console logs suggesting that the debugger could not retrieve source maps. When I navigate to the app on port 3000 (unproxied, without Windows authentication), everything works. It also works on port 5000 (proxied) when I disable Windows authentication temporarily.

I saw microsoft/vscode-chrome-debug-core#5, so I think supporting Windows authentication isn’t really an easy thing to do. It would be great if there were some other means to retrieve the source maps though. Retrieving the files via the local file system, or even through that other unproxied and unauthenticated server on port 3000 would be great. Maybe it would be possible to allow some explicit configuration for source map files (e.g. "/dist/bundle.js.map": "http://localhost:3000/bundle.js.map", or even with a local path using file://).

Since this proxied setup is a standard setup from the ASP.NET Core SPA templates, I would assume that this would help others as well.

[connor4312]

Depending on how you have the app set up, there may be options. create-react-app is quite opaque, but if you have a webpack config file you have quite a few options. Namely you can set the public path to an HTTP or file URI to indicate where sourcemaps should be loaded from. Alternately you can set the devtool to inline-source-map to avoid having separate sourcemap files entirely.

[poke]

@connor4312 Sadly, I am indeed using create-react-app, so I cannot just enable inline source maps. I have created an issue over there in the hope that they might add some way to allow inline source maps.

I tried multiple alternatives now and have a (not so nice) workaround now that works for my particular app at the moment, but of course I would really like to see some sort of support from the VS Code side itself.