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

Disabled or custom UUID for V8 inspector #9185

Closed
targos opened this issue Oct 19, 2016 · 45 comments
Closed

Disabled or custom UUID for V8 inspector #9185

targos opened this issue Oct 19, 2016 · 45 comments
Labels
diag-agenda Issues and PRs to discuss during the meetings of the diagnostics working group. inspector Issues and PRs related to the V8 inspector protocol question Issues that look for answers.

Comments

@targos
Copy link
Member

targos commented Oct 19, 2016

  • 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 targos added question Issues that look for answers. inspector Issues and PRs related to the V8 inspector protocol labels Oct 19, 2016
@targos
Copy link
Member Author

targos commented Oct 19, 2016

/cc @nodejs/v8-inspector

@ofrobots
Copy link
Contributor

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
Copy link
Member Author

targos commented Oct 20, 2016

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
Copy link

derenio commented Oct 25, 2016

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
Copy link
Member

bnoordhuis commented Oct 25, 2016

@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
Copy link
Contributor

dnalborczyk commented Oct 25, 2016

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
Copy link
Contributor

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

@eugeneo
Copy link
Contributor

eugeneo commented Oct 25, 2016

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
Copy link
Contributor

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
Copy link
Contributor

mscdex commented Oct 31, 2016

+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
Copy link
Contributor

ofrobots commented Nov 1, 2016

@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
Copy link

june07 commented Nov 16, 2016

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
Copy link

@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
Copy link
Contributor

eugeneo commented Nov 18, 2016

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

@jscheel
Copy link

jscheel commented Nov 18, 2016

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
Copy link
Contributor

jsumners commented Dec 1, 2016

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
Copy link

june07 commented Dec 2, 2016

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

chrome plugin

@muzuiget
Copy link

muzuiget commented Dec 4, 2016

Finally, I write a proxy server to workaround this

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

Hope can help.

@th317erd
Copy link

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
Copy link
Member

cc @nodejs/diagnostics

@simov
Copy link
Contributor

simov commented Mar 23, 2017

@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
Copy link
Contributor

jkrems commented Mar 23, 2017

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.

screen shot 2017-03-23 at 3 07 58 pm

  • "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
Copy link

june07 commented Mar 23, 2017 via email

@targos
Copy link
Member Author

targos commented Mar 24, 2017

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

@targos targos closed this as completed Mar 24, 2017
@jsumners
Copy link
Contributor

@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
Copy link
Member

@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
Copy link
Member

gibfahn commented Mar 24, 2017

@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
Copy link
Contributor

@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
Copy link
Member

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

@jkrems
Copy link
Contributor

jkrems commented Mar 24, 2017

@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
Copy link
Member

gibfahn commented Mar 24, 2017

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
Copy link
Contributor

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

@eugeneo
Copy link
Contributor

eugeneo commented Mar 27, 2017

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
Copy link
Contributor

rainabba commented May 16, 2017

@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
Copy link
Contributor

eugeneo commented May 16, 2017

@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
Copy link
Contributor

@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)

@joshgav joshgav added the diag-agenda Issues and PRs to discuss during the meetings of the diagnostics working group. label May 16, 2017
@j3bb9z
Copy link

j3bb9z commented Dec 12, 2017

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.

stupid_security_ideas

@bnoordhuis
Copy link
Member

@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
Copy link

j3bb9z commented Dec 12, 2017

@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
Copy link

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
Copy link
Member

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
Copy link

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
Copy link
Contributor

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
Copy link

flyte commented Aug 23, 2021

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
Copy link

BryanDollery commented Apr 24, 2022

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
diag-agenda Issues and PRs to discuss during the meetings of the diagnostics working group. inspector Issues and PRs related to the V8 inspector protocol question Issues that look for answers.
Projects
None yet
Development

No branches or pull requests