participants have to authenticate even with user_auth: false
-
@nebulon on this page https://docs.mirotalk.com/mirotalk-sfu/host-protection/ it says:
Host Protection Logic:
If host.protected is set to true, the following logic applies:
- Host login with username and password is required.
- Upon successful login, the IP is saved as a valid authentication IP.
- After authentication, the host can create a room, join a room, and share the room link.
- All guests can join until the host logs out.
- When the host leaves the room or exits the browser, their IP is removed from valid auth IPs to prevent unauthorized access.
- To access it again, the host needs to provide a username and password.
- If host.user_auth is set to true, additional authentication is required.
-
@imc67 said in participants have to authenticate even with user_auth: false:
@nebulon on this page https://docs.mirotalk.com/mirotalk-sfu/host-protection/ it says:
Host Protection Logic:
If host.protected is set to true, the following logic applies:
- Host login with username and password is required.
- Upon successful login, the IP is saved as a valid authentication IP.
- After authentication, the host can create a room, join a room, and share the room link.
- All guests can join until the host logs out.
- When the host leaves the room or exits the browser, their IP is removed from valid auth IPs to prevent unauthorized access.
- To access it again, the host needs to provide a username and password.
- If host.user_auth is set to true, additional authentication is required.
@nebulon can it be that the app doesn’t use the host’s IP but the container “internal” IP like some apps do sometimes keeps asking for authentication?
-
This does not really clear up things for me and I am not sure how this is IP related. Either way setting any auth/protection does show the login in my tests, as expected, and works with the users from the config file.
Maybe I don't understand what the issue is then I guess.
-
This setting:
host: { protected: true, user_auth: false,
should make it possible to start as host an authenticated video conference and ANY participant that has the URL can join without authentication.
According to the docs it is done by storing the IP of the host (who started the video conference)…..
-
Ah thanks for the clarification, I missed "All guests can join until the host logs out." but yes I also alwasy get the authentication wall, so something isn't working as expected. @imc67 if you know your way around Javascript maybe you can dig through the upstream code if you have some time to help diagnose this.
-
Hi everyone, Please try it now in the MiroTalk SFU v1.4.16. If the issue persists, then as soon as I have a bit more time available, I'll take a deeper look into it.
Any contributions to the project are always highly valued and appreciated!
Thank you all for your involvement in MiroTalk SFU.
We'll keep making it better with your feedback! -
I was very hopeful but it still doesn’t work as expected, the participant still needs to login while the host is online and waiting. Tested in Safari iPadOS and Safari iOS.
-
@imc67 said in participants have to authenticate even with user_auth: false:
I was very hopeful but it still doesn’t work as expected, the participant still needs to login while the host is online and waiting. Tested in Safari iPadOS and Safari iOS.
And I just tested in Firefox too. Same thing.
-
@imc67 said in participants have to authenticate even with user_auth: false:
This setting:
host: { protected: true, user_auth: false,
should make it possible to start as host an authenticated video conference and ANY participant that has the URL can join without authentication.
It should be fixed in the latest MiroTalk SFU version 1.4.18.
-
Update failed, uninstall and new install works!
-
@imc67 said in participants have to authenticate even with user_auth: false:
Update failed, uninstall and new install works!
Great!
Now I just have to wait for the port conflict issue to be fixed on Cloudron (which I mistakenly thought had already happened) and then I can give it another try!
-
@jdaviescoates port conflict issue is already fixed in 7.7.2 .
-
-