connecting to marionette server on the docker-firefox container is apparently failing due by invalid user permission

[pcbuildpluscoding]

Hi, About docker-firefox build arrangement that setups up the 'app' user as the executor of the firefox process group (which is a good idea) About the firefox cli flag --marionette which starts marionette server on startup if provided To accomplish this I forked docker-firefox and added the --marionette flag to the startapp.sh script =>

exec /usr/bin/firefox_wrapper --marionette --profile /config/profile --setDefaultBrowser >> /config/log/firefox/output.log 2>> /config/log/firefox/error.log

Initially my first testing setup added my compiled golang web-scraping binary, called dataminer, to the roofs/usr/bin folder, which I built producing a custom image I started the custom docker-firefox:marionette image in a container called firefox and opened my browser at localhost:5800 and all was good Then I ran > docker exec -it firefox /usr/bin/dataminer which ran as expected, installing my web-scraper addon The firefox browser view showed that my addon was installed. I test ran it and it worked fine

My goal is to run my dataminer binary in a separate container connecting to the custom firefox container and marionette server remotely to install addons My 2 container setup so far has failed when my dataminer app tries to open a remote tcp connection on port 2828. The log shows : connection refused I have setup a dedicated docker bridge network adding the --network arg to the docker run command for each container To try debugging, I docker exec-ed into the firefox container running > netstat -tulpn | grep LISTEN

tcp        0      0 0.0.0.0:5800            0.0.0.0:*               LISTEN      3089/nginx.conf -g 
tcp        0      0 127.0.0.1:2828          0.0.0.0:*               LISTEN      -
tcp        0      0 0.0.0.0:5900            0.0.0.0:*               LISTEN      3114/x11vnc
tcp        0      0 127.0.0.11:45697        0.0.0.0:*               LISTEN      -

This shows marionette is running on port 2828 as expected Also ran > ps

 3233 app       0:00 {firefox_wrapper} /bin/sh /usr/bin/firefox_wrapper --marionette --profile /con
 3263 app       0:03 {GeckoMain} /usr/bin/firefox --marionette --profile /config/profile --setDefau
 3341 app       0:00 {Privileged Cont} /usr/lib/firefox/firefox -contentproc -childID 1 -isForBrows
 3395 app       0:01 {WebExtensions} /usr/lib/firefox/firefox -contentproc -childID 2 -isForBrowser
 3446 app       0:00 {Web Content} /usr/lib/firefox/firefox -contentproc -childID 3 -isForBrowser -

This shows that the firefox process group is executed by user app I ran > cat /etc/passwd, it shows app user has the user id and group id couple => 1000:1000 With this info, I was hoping that by adding a corresponding user with 1000:1000 ids, the corresponding user profile would eliminate any user permission blocking But after adding the useradd and groupadd code to my dataminer Dockerfile, rebuilding and rerunning still produced the same error => connection refused To proof that the network was working as expected, I execed into the dataminer container and pinged the firefox container My terminal showed packets received correctly I ran > whoami which returned => app

Could you please advise what might be the root issue?

[pcbuildpluscoding]

I looked in the firefox about:config settings finding all items that include 'remote', hoping that a config item might be the issue Nothing super obvious stood out like enable.remote.connections=true/false There is a safebrowsing group that includes browser.safebrowsing.downloads.remote.block_dangerous_host which by default = true I'll turn these off and give it a try

[jlesage]

connection refused usually means that the port is not open. Did you exposed port 2828 via the -p parameter ?

[pcbuildpluscoding]

Did you exposed port 2828 via the -p parameter ?

@jlesage As I recall, I did figure out that this issue should be resolved by port forwarding. So I added EXPOSE 2828 to my forked version of docker-firefox and added -p 2828:2828 to the run command. As I recall, it still didn't work. It should work ! I probably had a typo somewhere that caused it to fail. In the end, I solved the problem by making a proxy service that runs on remote port 2929 as an exec process after firefox starts. Sounds like a lot of work? Not really ... and this allowed 1. waiting for firefox to start 2. easier and better debugging of marionette protocol 3. learning more about packet encoding and decoding

[j-mendez]

@jlesage by default request to the firefox instance inside the docker container without a proxy does not work. If you try to curl http://127.0.0.1:5800/json/version when starting the instance with --remote-debugging-port=5800 and simply using the image to download the binary of firefox.

[jlesage]

You cannot use --remote-debugging-port with the same port as the container web interface. You need to use a different one. Also, from what I understand, this option creates a web server instance listening on localhost only. That means that if you create the container with the default bridge network, you can access the debug interface only when inside the container. The other solution is to create the container with the host network: in this case, you should be able to access the interface from the host running the container.

[OLibutzki]

I guess this is related to #153.

In Chrome it seems to work using CDP for the remote debugging session: https://github.com/yukinying/chrome-headless-browser-docker

docker run --init -it --rm --name chrome --shm-size=1024m -p=127.0.0.1:9222:9222 --cap-add=SYS_ADMIN \ yukinying/chrome-headless-browser