non localhost remote debugging has insecure websocket issue in headless mode
Reported by
sgh...@gmail.com,
May 3 2017
|
||||||
Issue descriptionUserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3071.29 Safari/537.36 Steps to reproduce the problem: 1. Start chrome in headless mode and enable remote debugging: google-chrome-beta --headless --disable-gpu --remote-debugging-port=9999 https://www.chromestatus.com 2. Create a tunel to allow to connect to remote debugging from another hostname ssh -L 0.0.0.0:5656:localhost:9999 localhost -N 3. On your browser navigate to [headless-chrome-host-ip]:5656 (in my case: http://192.168.0.41:5656/) and click one of the available link to access the debugger. What is the expected behavior? The page opened in the headless browser should show up What went wrong? Nothing appears, only an empty developer tool window. When opening the console of the browser the following issue appears: inspector.js:3303 Mixed Content: The page at 'https://chrome-devtools-frontend.appspot.com/serve_file/@dcd2d6617b9c77d95a…656/devtools/page/d84d50ff-bf95-4a05-b2e0-d7fd2e181551&remoteFrontend=true' was loaded over HTTPS, but attempted to connect to the insecure WebSocket endpoint 'ws://192.168.0.41:5656/devtools/page/d84d50ff-bf95-4a05-b2e0-d7fd2e181551'. This request has been blocked; this endpoint must be available over WSS. Uncaught DOMException: Failed to construct 'WebSocket': An insecure WebSocket connection may not be initiated from a page loaded over HTTPS. at new SDK.WebSocketConnection (https://chrome-devtools-frontend.appspot.com/serve_file/@dcd2d6617b9c77d95a69625720bec83c6e519f1d/inspector.js:3303:430) at SDK.TargetManager._createMainConnection (https://chrome-devtools-frontend.appspot.com/serve_file/@dcd2d6617b9c77d95a69625720bec83c6e519f1d/inspector.js:3267:203) at SDK.Target.Protocol.TargetBase (https://chrome-devtools-frontend.appspot.com/serve_file/@dcd2d6617b9c77d95a69625720bec83c6e519f1d/inspector.js:3089:501) at SDK.Target (https://chrome-devtools-frontend.appspot.com/serve_file/@dcd2d6617b9c77d95a69625720bec83c6e519f1d/inspector.js:3169:3232) at SDK.TargetManager.createTarget (https://chrome-devtools-frontend.appspot.com/serve_file/@dcd2d6617b9c77d95a69625720bec83c6e519f1d/inspector.js:3243:82) at SDK.TargetManager._connectAndCreateMainTarget (https://chrome-devtools-frontend.appspot.com/serve_file/@dcd2d6617b9c77d95a69625720bec83c6e519f1d/inspector.js:3266:17) at SDK.TargetManager.connectToMainTarget (https://chrome-devtools-frontend.appspot.com/serve_file/@dcd2d6617b9c77d95a69625720bec83c6e519f1d/inspector.js:3263:129) at Main.Main._initializeTarget (https://chrome-devtools-frontend.appspot.com/serve_file/@dcd2d6617b9c77d95a69625720bec83c6e519f1d/inspector.js:8165:78) Did this work before? N/A Chrome version: 59.0.3071.29 Channel: beta OS Version: Flash Version: - The previous example works when accessing the remote debugger from the address localhost:9999 on the same host - The whole process (including port forwarding) works when debugged chrome instance is not start in headless mode: google-chrome-beta --remote-debugging-port=9999 https://www.chromestatus.com
,
May 4 2017
sghzal@, can you please upgrade to the latest beta build # 59.0.3071.36 available & check if you still see this issue ?
,
May 5 2017
Yes it still happens with latest version (59.0.3071.36). I attached a short screencast to show the actual issue
,
May 5 2017
Thank you for providing more feedback. Adding requester "pucchakayala@chromium.org" to the cc list and removing "Needs-Feedback" label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Jun 1 2017
,
Jun 1 2017
,
Dec 11 2017
WontFix due to lack of priority / resources |
||||||
►
Sign in to add a comment |
||||||
Comment 1 by brajkumar@chromium.org
, May 4 2017