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