Repository navigation
Disabled or custom UUID for V8 inspector #9185
Description
Activity
/cc @nodejs/v8-inspector
A temporary work-around could be something like (assuming you have
jqand are on a Mac):( sleep 1; open $(curl -s http://localhost:9229/json/list | jq -r '.[0].devtoolsFrontendUrl') ) & node --inspect --debug-brk script.js
Reacted by Miguel Angel Asencio Hurtado, Mateusz Dereniowski and Jaime AgudoThank 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
9229port then one can get theUUIDfrom thehttp://localhost:9229/jsonpage (as in the @ofrobots workaround). Otherwise theUUID-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.
Reacted by Franklin Dattein, Getitdan, Joseph Brasch, Michael Uvarov and Glade Luco@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.
Reacted by Mateusz Dereniowski, Gibson Fahnestock and GetitdanMakes 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!
... or, maybe, as @targos suggested, instead of turning UUID re-generation off, maybe instead apply a custom path parameter?
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.
Reacted by Praneet RohidaThis 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 --inspectfor 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")+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.
Addressed this in #2546 but it's a closed issue.
The following plugin helps in this case:
chrome pluginIt 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.
Reacted by Dmytro Haponov, Mike Staub, Sander Bouwhuis, zanemayo, Aleksandr Murin, Thabang Thamane and 哈哈胡子@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"19 remaining items
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.
@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
@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.
@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)
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.
@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.
@bnoordhuis That wasn't the case, I've set the port by
--inspect=5858. Also tried the default9229ports 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 . :(
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
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.
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 youWhy 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.
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/versioneach 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!Reacted by Awada and Glade LucoIMO: 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.
Reacted by Boky, dkmaczynski and Joe Ferner
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 ?