I notice that there are discussions about the next release allowing for port changes, which will be great.
For now, I’d really like to prevent people accessing the chat demo type interface when you go to the ip address of the server. If i go to /dashboard/ I notice that I have to enter in the username/password combo. Can I do this to the ‘front page’ example interface (I’m sorry, I’m not sure what you call it). It’s all very public at the moment.
What are the general guidelines for locking down access so that we make the API accessible to our app but disable (or at least restrict) access to it directly through a browser?
nb. I have OpenVidu on an external server (on aws) and the application on a separate server- this is the use case I’m looking to sure up.
I suppose you have deployed OpenVidu platform and the demo application OpenVidu Call. This demo application, allows anyone to create a session.
If you plan to deploy your own application in another server, just disable OpenVidu Call removing docker-compose.overrides.yml file. In that way, only using your application the people could create sessions.
To protect OpenVidu API, just configure a SECRET that only your application knows. Also, do not put this SECRET in front-end code. Use it ONLY in your backend.
It is now more clear?
Ah ,thanks Michael. Yes, the API requires a secret, and I’ll make sure it’s only used server side. When you say I can remove, docker-compose.overrides.yml, where is that, and is it just a matter of deleting the file? If I remove this file, will it disable the OpenVidu Call app?
Thanks so much for your guidance.
The file docker-compose.override.yml is localted in /opt/openvidu/.
Yes, you can delete it and restart OpenVidu platform and OpenVidu Call application is disabled.
I have removed the file and rebooted and the call app is still accessible as it was before. Ive checked several time and it definitely gone, and have certainly rebooted. Any idea what else i can try?
Have you restarted openvidu with command?
$ sudo su
$ cd /opt/openvidu
$ ./openvidu restart
You have to restart openvidu, not the machine.
Please execute the following command after openvidu restart and share the results:
$ docker ps -a
CONTAINER ID IMAGE COMMAND CREATED
STATUS PORTS NAMES
c4b72cf97d98 openvidu/openvidu-coturn:1.0.0 “/bin/sh -c /usr/loc…” 15 minutes ago
Up 15 minutes openvidu_coturn_1
6af544d55fba openvidu/openvidu-server:2.13.0 “/bin/bash -c 'expor…” 15 minutes ago
Up 15 minutes openvidu_openvidu-server_1
06c16fc33ba0 redis:5.0.7 “docker-entrypoint.s…” 15 minutes ago
Up 15 minutes openvidu_redis_1
0955287bceb0 openvidu/openvidu-proxy:1.0.0 “/bin/sh -c /usr/loc…” 15 minutes ago
Up 15 minutes openvidu_nginx_1
4ca0a76a3840 kurento/kurento-media-server:6.13.1 “/entrypoint.sh” 15 minutes ago
Up 15 minutes (healthy) openvidu_kms_1
eaf07e7c6963 openvidu/openvidu-call:2.12.0 “/bin/sh -c /usr/loc…” 5 days ago
Up 50 minutes 0.0.0.0:5442->80/tcp openvidu_app_1
Hi
Same problem on my server.
I deleted the yml file but call still accessible.
sudo docker ps -a
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
d528fe91f985 openvidu/openvidu-coturn:1.0.0 “/bin/sh -c /usr/loc…” 3 minutes ago Up 3 minutes openvidu_coturn_1
8542445a983b redis:5.0.7 “docker-entrypoint.s…” 3 minutes ago Restarting (1) 20 seconds ago openvidu_redis_1
c3433cd6aaee kurento/kurento-media-server:6.13.2 “/entrypoint.sh” 3 minutes ago Up 3 minutes (healthy) openvidu_kms_1
3fa6a4f912fe openvidu/openvidu-proxy:2.0.0 “/bin/sh -c /usr/loc…” 3 minutes ago Up 3 minutes openvidu_nginx_1
9d4d7f9b0be3 openvidu/openvidu-server:2.14.0 “/bin/bash -c 'expor…” 3 minutes ago Up 3 minutes openvidu_openvidu-server_1
307466fb7b5a openvidu/openvidu-call:2.14.0 “docker-entrypoint.s…” 17 minutes ago Up 9 minutes 0.0.0.0:5442->5000/tcp openvidu_app_1
openvidu-call container is still there:
Execute the following command to kill it:
$ docker rm -f 307466fb7b5a
Thanks Michael, the docker container you proposed was for icap84, but i figured it out with your help. Many thanks
Yep… I take into account later 