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

fix: unable to remotely connect to chrome #334

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

clemensm
Copy link

Chrome requires the "host" header to be set to either an ip address or "localhost", otherwise it will not accept the connection.

I've fixed it by requesting a "localhost" host, and then manually patching the websocket address in the reply from Chrome. The use case here would be a docker container running with Zenika/alpine-chrome, and my application in another docker container, with a shared network. Otherwise this might work with fixed IP's as well.

Chrome requires the "host" header to be set to either an ip address or "localhost", otherwise it will not accept the connection
@maltoe
Copy link
Collaborator

maltoe commented Dec 19, 2024

Hi @clemensm

thank you! Is this related to #327? Meaning, Chrome does accept remote connections when the host header is set? Or do you have to run socat in addition to this?

@clemensm
Copy link
Author

Hi Malte, yeah, I think this is related to #327, at least I was unable to get a Chrome connection without the header, and without setting it to "localhost" or 127.0.0.1.

So I'm running the docker container using:

podman container run -d --rm --name chrome --network development zenika/alpine-chrome:latest --no-sandbox --remote-debugging-address=0.0.0.0 --remote-debugging-     port=9222

With the remote-debugging-address still set to 0.0.0.0, but without the header no luck in connecting.

And no, I do not need to use socat in this case, just the container as it is in the above command.

@maltoe
Copy link
Collaborator

maltoe commented Dec 20, 2024

🤔

--remote-debugging-address=0.0.0.0

But this is specifically what @MaeIsBad said in #327 wouldn't work anymore with recent Chromium. Don't get me wrong, I'm not opposed to the change you suggest at all, but I'd like to have a reasonable plan forward for remote chrome users, ideally incl. documentation.

What chromium version do you get from zenika/alpine-chrome:latest currently? Also, I'm assuming the podman network is a bridge network? Could you try isolate the container and connect through a remote address?

@clemensm
Copy link
Author

clemensm commented Dec 20, 2024

Regarding your questions:

zenika/alpine-chrome:latest is Chrome:124, the newest tag I can find in their container repositories, so maybe with a newer Chrome this will no longer work... Which version of Chrome removes the --remote-debugging-address=0.0.0.0 switch, do you happen to know that?

You are right that the network is a bridged network, that's the default podman creates on Mac 😄. I've tried to create a non-bridged network, but so far I've failed with that, but I'll try to test it later using an acutal network connection to my homelab server, maybe that will help finding out if it is working

@clemensm
Copy link
Author

So reading through the Chrome issue tracker that is linked from #327, it seems that the version of Chrome I'm running now is older and still has the --remote-debugging-address=0.0.0.0 switch. Also it seems that it is not going to come back, so we'll need to use socat in the future ....

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants