fix: #216 Configure with ws/wss url #435
Conversation
|
|
||
| if options.ws_url | ||
| response = parse_json_version(options.ws_url) | ||
| self.ws_url = response&.[]("webSocketDebuggerUrl") || options.ws_url |
There was a problem hiding this comment.
@route in this case, the final result will still be whichever value headless server returns.
Imagine a case with docker-compose and Headless Chrome (2.0) available over "chrome" hostname, with ws_url then being ws://chrome:4000 (with then "chrome" resolving to the IP of the chrome container and not to localhost. In this scenario, even thought options.ws_url is ws://chrome:4000, Chrome will return the following:
=> {"Browser"=>"HeadlessChrome/121.0.6167.57",
"Protocol-Version"=>"1.3",
"User-Agent"=>"Mozilla/5.0 (X11; Linux aarch64) AppleWebKit/537.36 (KHTML, like Gecko) HeadlessChrome/121.0.6167.57 Safari/537.36",
"V8-Version"=>"12.1.285.20",
"WebKit-Version"=>"537.36 (@add6d6ffbc3a1c7e78cc15e6ba2dcb15208bedd5)",
"webSocketDebuggerUrl"=>"ws://0.0.0.0:4000",
"Debugger-Version"=>"add6d6ffbc3a1c7e78cc15e6ba2dcb15208bedd5"}
and Ferrum will assign ws_url to ws://0.0.0.0:4000. This value is then used for connections from the container running Ferrum (for example, Rails container with Cuprite) -> those connections won't work, as there is no Chrome running on 0.0.0.0:4000, it's running on chrome:4000.
There was a problem hiding this comment.
Ignore what I wrote, I just noticed it's already fixed here a981af2, but it's not yet released.
There was a problem hiding this comment.
Yea release is going to happen in 1-2 weeks I think.
No description provided.