Disabled or custom UUID for V8 inspector

[targos]

• Version: 6.9.0
• Subsystem: V8 inspector

I got used, for debugging, to open a Chrome tab with the inspector URL and just reload it each time I make a change to my code and restart the node process.
Now that a new UUID is generated on restart, I have to copy the URL every time.
Unless I'm doing something wrong and there is an easier way to work with the V8 inspector, could we add a command line option to force a custom URL path or disable the UUID ?

[targos]

/cc @nodejs/v8-inspector

[ofrobots]

A temporary work-around could be something like (assuming you have jq and are on a Mac):

( sleep 1; open $(curl -s http://localhost:9229/json/list | jq -r '.[0].devtoolsFrontendUrl') ) & node --inspect --debug-brk script.js

[targos]

Thanks @ofrobots. I adapted your work-around for Fedora with:

( sleep 1; google-chrome $(curl -s http://localhost:9229/json/list | jq -r '.[0].devtoolsFrontendUrl') ) & node --inspect --debug-brk script.js

[derenio]

Thank you @targos for creating this issue and @ofrobots for the workaround!

I've got an additional question about the purpose of the UUID in the url. According to the changelog for 6.9.0 release:

v8_inspector: Generate a UUID for each execution of the inspector. This provides additional security to prevent unauthorized clients from connecting to the Node.js process via the v8_inspector port when running with --inspect. (...)

I don't understand how this is an additional "security".

If I already expose the 9229 port then one can get the UUID from the http://localhost:9229/json page (as in the @ofrobots workaround). Otherwise the UUID-less url isn't a security risk because the port is closed.

Am I missing something? So far this "feature" is only an annoyance for the developers.

[bnoordhuis]

@derenio The threat model is an attacker tricking you into visiting their malicious URL. The JS on that page won't be able to XHR to http://localhost:9229/json because of the Same Origin Policy but a connection to ws://localhost:9229/ would be accepted by the browser because it's not subject to the SOP. The GUID in the ws:// URL stops that from working.

[dnalborczyk]

Makes sense, thanks @bnoordhuis. Does that justify the UUID re-generation though? If so, could we add a parameter for turning the UUID re-generation off? The docs could make the developers aware of a possible security problem, and in turn they can decide for themselves. I agree with @targos , it's quite annoying unfortunately - of an otherwise great feature!

[dnalborczyk]

... or, maybe, as @targos suggested, instead of turning UUID re-generation off, maybe instead apply a custom path parameter?

[eugeneo]

Command line option should not be hard to implement - the problem I see with significant portion of people defaulting to some obvious ID (e.g. "node") or what some popular online StackOverflow/Reddit solution uses.

One more complex solution that might be considered is creating UUID from user name/script name.

[rainabba]

This new uid behavior has had a direct impact on my debugging productivity. The node-v8-inspector extension ( cjihrig/node-v8-inspector#13 ) saved me from having to find, copy the debug url, then paste into a new tab which was an improvement. I use nodemon --inspect for development and debugging. Previously, the page would just reconnect when nodemon restarted my app and I could continue working. With this change, that behavior is broken and the "Reconnect" button provided doesn't work because uid is different. Now I have to close the tab and re-open the extension. This is still far better than copying the url from a terminal, but it's a major step back from the previous behavior.

@eugeneo Your concern is valid on the surface, but considering what it would take for that to be a real security issue (someone that would leave their app running in debug mode with a predictable value and accessible by someone that would abuse it), that's likely the least of their concerns while the rest of us are affected in very real ways.

Perhaps I'm missing something here, but I don't see why the id needs to change when it was so unique to begin with. I could see using something like the command string and date as a seed to generate one (so it changes each day and with a new command). This would keep it strong, unpredictable to outsiders, but not require constant changes that create the issue I'm dealing with,

The following would accomplish my suggestion (hash of hostname, date and launch command/args):

Stealing an idea from here, crypto.createHash("md5").update(os.hostname() + new Date().toDateString() + process.argv.join("")).digest("hex")

[mscdex]

+100 Having to copy and paste every time is a hassle. I think this would be less of an issue (at least for me) if most terminals linked the chrome URL so you could just click on it. However, being able to simply refresh the page or click the reconnect button in Chrome would be the best solution IMHO.

[ofrobots]

@mscdex we have some ideas on getting 'refresh' in the debugger to restart the node process .. we're hoping we can find time to work on that soon. /cc @eugeneo

[june07]

Addressed this in #2546 but it's a closed issue.

The following plugin helps in this case:
chrome plugin

It gives you the option of auto opening and closing the DevTools window in a tab or window. Just change the toggle from Manual to Auto and then start a debugging session. DevTools should open. And once you end your debugging session, DevTools will close.

I was having the same issue a few days ago and wrote a Chrome extension to solve it. Would love any feedback.

[aegyed91]

@ofrobots @targos the workaround only works on initial start. When nodemon restarts the application on file change it wont open another tab in chrome. Any ideas how to hax it in there too until there is an official solution?

( sleep 1; google-chrome $(curl -s http://localhost:9229/json/list | jq -r '.[0].devtoolsFrontendUrl') ) & nodemon --inspect server.js"

[eugeneo]

@tsm91 Nodemon could work as a devtools proxy - similar to https://github.com/eugeneo/node-restarter/blob/master/restarter.js

[jscheel]

Ok, I have the most ghetto temporary solution possible for OSX. Basically, I use an iTerm2 trigger to watch for the url, then run a bash script that executes an applescript which interfaces with Chrome.

https://gist.github.com/jscheel/152431a9b8d2753800fae6d2f536d50b.

I also added an option to it to replace localhost with a different hostname.

[jsumners]

I'd really like the option to disable the uuid. I am almost always debugging locally. Having to copy and paste a new URL for each debugging session I opt to do without IntelliJ or VS Code is very annoying. Even if I'm going debug a remote process I am going to do it over an SSH connection. So the uuid really doesn't do anything for me except inhibit getting work done.

[june07]

Alleviates the need for messing with the uuid, copy/paste, open/close.

chrome plugin

[muzuiget]

Finally, I write a proxy server to workaround this

https://github.com/muzuiget/node-inspector-proxy

Hope can help.

[th317erd]

This is completely stupid and frustrating. You are affecting thousands of developers around the globe by forcing a security measure that is EXTREMELY edge-case, and then you do not even provide a method of overriding this "feature"? Do you see how much pain and effort you have caused the community simply by not providing a flag to turn it off? Please provide the community with a way to disable the ludicrous "security feature". Please fix this promptly.

[richardlau]

cc @nodejs/diagnostics

[simov]

@th317erd I'm using https://github.com/muzuiget/node-inspector-proxy from #9185 (comment) I have it running with forever in the background. Not the perfect solution because it requires you to search and read through this thread, but in the meantime it's just another node process running on my workstation.

[jkrems]

There's a neat way to work around this (assuming you're running --inspect with a limited number of ports, or preferably even with the default port): You can use the chrome://inspect UI.

• "Open dedicated DevTools for Node" opens up an instance of DevTools that automatically connects to node --inspect's default port and will continue to work across restarts of node (it detects the UUID automatically).
• If you're using different port(s), you can use "Configure..." next to "Discover network targets" to add them. From then on getting a fresh debugger is just a click on "inspect" away.

Tools like node inspect my-script.js and Visual Studio Code work similar to the "dedicated DevTools for Node" - they hit http://<host>:<port>/json and get both the proper UUID and nice meta information.

TL;DR: Generally speaking and as tools improve, you shouldn't need to copy&paste the UUID in practice. That details can be hidden away because the protocol allows discovery.

[june07]

This has been a solution for some time now. https://twitter.com/wesbos/status/839871649738555393 http://june07.com/nim

…

On Mar 23, 2017 3:14 PM, "Jan Olaf Krems" ***@***.***> wrote: There's a neat way to work around this (assuming you're running --inspect with a limited number of ports, or preferably even with the default port): You can use the chrome://inspect UI. [image: screen shot 2017-03-23 at 3 07 58 pm] <https://cloud.githubusercontent.com/assets/567540/24272439/9d5506b6-0fda-11e7-889d-70304dcbc147.png> - "Open dedicated DevTools for Node" opens up an instance of DevTools that automatically connects to node --inspect's default port and will continue to work across restarts of node (it detects the UUID automatically). - If you're using different port(s), you can use "Configure..." next to "Discover network targets" to add them. From then on getting a fresh debugger is just a click on "inspect" away. Tools like node inspect my-script.js and Visual Studio Code work similar to the "dedicated DevTools for Node" - they hit http://<host>:<port>/json and get both the proper UUID and nice meta information. TL;DR: Generally speaking and as tools improve, you shouldn't need to copy&paste the UUID in practice. That details can be hidden away because the protocol allows discovery. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#9185 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AK099iakLeTUKwDXQLhVTbU-3hLvJeEnks5rou6-gaJpZM4Ka4Av> .

[targos]

I'm going to close this issue. There are many working solutions now.

[jsumners]

@targos nothing outside side of Node itself providing the ability to disable the UUID is a "solution". Those are workarounds at best. I do not consider this resolved. I have no desire to install external tools.

[bnoordhuis]

@jsumners You can pull the URL from http://127.0.0.1:9229/json/list. If that's not good enough for you, tough cookies.

[gibfahn]

@jsumners pretty sure @jkrems solution in #9185 (comment) doesn't require any external tools (or require copy-pasting). What about that doesn't work for you?

[jsumners]

@gibfahn even @jkrems called it a "work around". At the very least his suggestion should be in the documentation as the solution to this issue -- https://nodejs.org/api/cli.html#cli_inspect_host_port

I certainly never would have learned about it outside of this thread.

[bnoordhuis]

I agree. Fortunately we accept documentation pull requests. Any takers?

[jkrems]

@jsumners Maybe a communication style mismatch - I tend to call any solution short of "the computer appears to read my mind" a work around... ;)

[gibfahn]

The documentation issue seems related to #11207, we probably want to link people to the guide on nodejs.org from the docs and the node --inspect prompt.

As @jkrems pointed out in #11207 (comment), having the URL is now probably counter-productive. We should be encouraging users to open their debugger of choice (e.g. Chrome Dev Tools or VS Code or whatever), which will automatically connect to the right port.

cc/ @joshgav

[jsumners]

It looks like if the issue @gibfahn linked is resolved then that could alleviate the problem.

[eugeneo]

In my opinion, all the issues around UUID should be solved on the frontend side (e.g. Chrome DevTools or IDEs). Frontends should be using JSON to discover the websocket URL and then accessing Node there.

[rainabba]

@eugeneo Ironic. Because of this issue, I tried to use NIM (auto-reconnects despite the UID change), but that's a "hosted instance of devtools" and has issues. Without the UID issue, I'd be using the built-in node support off of Chrome 60 (which is working great except that I have to copy/paste the damn UID every single time the app restarts which completely screws with my debugging technique.

Here's the kicker though, the Chrome Devtools team and appropriate developers say they can't do anything for Node LTS (6.x) because apparently LTS requires an older/broken devtools so NIM doesn't even help where LTS is concerned.

Right now this UID issue is a major impediment for development on LTS and the ONLY reason I've seen so far comes down to paranoi (yes, it's security, but overkill to the point of invalidating its existence since we have to hack around it and that will likely lead to FAR more and weaker attack vectors).

Here's what the DevTools team had to say about the issues around LTS debugging with NIM:

https://bugs.chromium.org/p/chromium/issues/detail?id=718202#c3

[eugeneo]

@rainabba that was me on the Chromium bugtracker...

Inspector support in the Node 6.x was experimental and was known to have some issues, one of them was the old protocol that is not supported by the new DevTools. That means that fixing the profiler issue would require shipping a new version of the old DevTools and there is no infrastructure for that. Newer Node versions use "latest" devtools so updating the Chrome will bring new DevTools.

[rainabba]

@eugeneo Wow. Makes sense, but makes "ironic" feel like ironic^∞

Put that way, it sounds like my expectations are too high since that feature was too new for 6.x.

I'm looking at this as "my node.js debugger", but now that I think about it, I realize that this may be more the devtools team doing than the node.js team and doesn't exist without both and 6.x just doesn't have the debugger I want.

It's just hard to reconcile those things with "LTS". I'd LOVE to be on 7.x and may even be able to justify "the risk", but to me, LTS exists for LOB apps and as other system (like 7.x) mature, those features make their way to the LTS.

From what you're saying though, Node.js won't get this debugger so long as LTS is based on the 6.x branch (and I'm not assuming that will ever happen).

Just trying to understand and set my expectations realistically (as I take a break from UID copy/pasting AKA debugging)

[j3bb9z]

Edit: It's fixed for PhpStorm 2017.3.

I use node on VM (vagrant) and PhpStorm as IDE. Currently I cannot connect to that "safer" url at all.

[bnoordhuis]

@jacob87o2 Seeing that it defaults to port 5858, I expect connecting with your IDE won't work anyway - that's the port number of the old debugger, the one that's been removed.

[j3bb9z]

@bnoordhuis That wasn't the case, I've set the port by --inspect=5858. Also tried the default 9229 ports and it didn't help.

However, it turned out that there was newer version of PhpStorm (2017.3), that I had yet to update... and after update it works!

So, yeah - thanks for the suggestion, but JetBrains actually solved the problem for me. Not sure about other people though. Without similar solution as the PhpStorm "remote node js debugging plugin", it might be still a problem . :(

[christopherreay]

So I came across this thread, wondering exactly the opposite. Why is there an url that serves the url with the UUID inside it. Personally I think thats nuts :)

My debugging life is very happy to copy the URL each time I run the project, and very happy that the URL changes all the time.

Im a bit worried about the URL being published the way it is, and I will try and work out how to secure that.

How do I secure that URL if I am remote debugging?
What I mean is, can I have the URL that serves the json/pdl with the url containing the UUID inside served only to local host, whilst still actually access the debugging socket?

thanks so much. This software is absolutely incredible

[bnoordhuis]

Why is there an url that serves the url with the UUID inside it.

@christopherreay it's explained here: #9185 (comment). If you're worried about external access, you could set up a VPN or ssh tunnel.

[christopherreay]

I understand that. sorry I was a bit lazy, I also wanted to chime I about supporting the security idea.
I'll look up the ssh tunnel. thank you

[ofrobots]

Why is there an url that serves the url with the UUID inside it.

FYI there is now updated documentation on the Debugging guide about the security implications, ssh tunnels, etc.

[flyte]

None of these workarounds help my use case, which is load-balancing a bunch of chromium instances behind a Kubernetes Service (for internal use only, not exposed). If I have to call /json/version each time to get the WS URL, then the next time I call the service to connect to the WS I'll hit a different instance with a different ID!

[BryanDollery]

IMO: the security argument is specious. This "feature" is just really annoying and stops me from doing my work. My security is already extreme, I don't need this in my development environment. If the devs insist on it, then can you please provide a way of switching it off for those of us who find it completely breaks their ability to work with node.