[GH-ISSUE #194] Protect container with basic authentification #136

New issue

Closed

opened 2026-03-01 15:40:49 +03:00 by kerem · 4 comments

kerem commented

2026-03-01 15:40:49 +03:00

Owner

Originally created by @yousefchtourou on GitHub (Aug 25, 2019).
Original GitHub issue: https://github.com/budtmo/docker-android/issues/194

💬 Questions and Help

Any idea to protect this container ?

any body in LAN ,

can press Ctrl+alt+supper to shutdown the emulator and fail the application

Originally created by @yousefchtourou on GitHub (Aug 25, 2019). Original GitHub issue: https://github.com/budtmo/docker-android/issues/194 ## 💬 Questions and Help Any idea to protect this container ? any body in LAN , ![emulator_samsung_galaxy_s6](https://user-images.githubusercontent.com/45118325/63649049-ac06df80-c730-11e9-95aa-b486631ec969.png) can press Ctrl+alt+supper to shutdown the emulator and fail the application

kerem closed this issue

2026-03-01 15:40:50 +03:00

kerem commented

2026-03-01 15:40:50 +03:00

Author

Owner

@Arne-B commented on GitHub (Aug 28, 2019):

Yeah, NoVNC uses websockify to provide a webserver. Websockify supports auth plugins, but the noVNC start script does not use this feature (as far as i could tell in a quick check). (${WEBSOCKIFY} ${SSLONLY} --web ${WEB} ${CERT:+--cert ${CERT}} ${KEY:+--key ${KEY}} ${PORT} ${VNC_DEST} ${RECORD_ARG} &)
This means, that this script from noVNC needs to be changed first, before support could be added in this project.

EDIT: I just saw, we are using a version from 2016, might be a good idea to update...

@Arne-B commented on GitHub (Aug 28, 2019): Yeah, NoVNC uses websockify to provide a webserver. Websockify supports auth plugins, but the noVNC start script does not use this feature (as far as i could tell in a quick check). (${WEBSOCKIFY} ${SSLONLY} --web ${WEB} ${CERT:+--cert ${CERT}} ${KEY:+--key ${KEY}} ${PORT} ${VNC_DEST} ${RECORD_ARG} &) This means, that this script from noVNC needs to be changed first, before support could be added in this project. EDIT: I just saw, we are using a version from 2016, might be a good idea to update...

kerem commented

2026-03-01 15:40:51 +03:00

Author

Owner

@ychtourou commented on GitHub (Aug 28, 2019):

protect by basic authentification for example

@ychtourou commented on GitHub (Aug 28, 2019): protect by basic authentification for example

kerem commented

2026-03-01 15:40:51 +03:00

Author

Owner

@Arne-B commented on GitHub (Aug 28, 2019):

setting a vnc password with
RUN mkdir /root/.vnc/
&& x11vnc -storepasswd password /root/.vnc/passwd

and running vnc with
command=/usr/bin/x11vnc -display %(ENV_DISPLAY)s -usepw -forever -shared

would make sure, that every vnc access it at least secure by a global default password which then must be changed at runtime.
I would suggest to introduce some ENV VAR which, if set, sets the vnc password and enables it.
The default can still be no password, because its an active choice to forward the vnc ports and enable external access.

@Arne-B commented on GitHub (Aug 28, 2019): setting a vnc password with RUN mkdir /root/.vnc/ \ && x11vnc -storepasswd password /root/.vnc/passwd and running vnc with command=/usr/bin/x11vnc -display %(ENV_DISPLAY)s -usepw -forever -shared would make sure, that every vnc access it at least secure by a global default password which then must be changed at runtime. I would suggest to introduce some ENV VAR which, if set, sets the vnc password and enables it. The default can still be no password, because its an active choice to forward the vnc ports and enable external access.

kerem commented

2026-03-01 15:40:51 +03:00

Author

Owner

@budtmo commented on GitHub (Sep 11, 2019):

Hi @ychtourou,

I dont give it, because it make easier to integrate with other tools (e.g. zalenium) and easier for user to open it (the user do not need to give the credentials everytime they want to see what happening and for testing purpose in my opinion it should be secured enough because you are in the same company network). probably the easiest solution is that you dont need to open any the vnc port and use screen recording if you want to see what happening during test execution. but you can share your use case why you want to protect the container in the same network, so maybe we can discuss the next step.

I will close it for now, but feel free to reopen it.

@budtmo commented on GitHub (Sep 11, 2019): Hi @ychtourou, I dont give it, because it make easier to integrate with other tools (e.g. zalenium) and easier for user to open it (the user do not need to give the credentials everytime they want to see what happening and for testing purpose in my opinion it should be secured enough because you are in the same company network). probably the easiest solution is that you dont need to open any the vnc port and use screen recording if you want to see what happening during test execution. but you can share your use case why you want to protect the container in the same network, so maybe we can discuss the next step. I will close it for now, but feel free to reopen it.