participants have to authenticate even with user_auth: false
-
same issue here, I would like to have only a username/password to be able to start a session and all the invited participants can use it immediately. Better would be OIDC or LDAP support because usernames and passwords stored in config files is sooo .......
-
@avatar1024 I will verify this as it is not the expected behavior.
Here the MiroTalk SFU host protection logic.
Better would be OIDC or LDAP support because usernames and passwords stored in config files is sooo .......
@imc67 MiroTalk does not utilize a persistent database except for the room scheduler within the MiroTalk WEB application. Within the MiroTalk Selective Forwarding Unit (SFU) configuration, there are options available to verify the validity of usernames and passwords through an API endpoint. By default, this endpoint is set to MiroTalk WEB but disabled. However, you have the flexibility to modify this endpoint to connect to your own database.
Below is the code snippet utilized to check users:
async function isAuthPeer(username, password) { if (hostCfg.users_from_db && hostCfg.users_api_endpoint) { try { const response = await axios.post(hostCfg.users_api_endpoint, { email: username, password: password, api_secret_key: hostCfg.users_api_secret_key, }); return response.data && response.data.message === true; } catch (error) { log.error('AXIOS isAuthPeer error', error.message); return false; } } else { // Check if the user is valid based on the locally stored user credentials return ( hostCfg.users && hostCfg.users.some((user) => user.username === username && user.password === password) ); } }Cheers,
Miroslav -
@avatar1024 I will verify this as it is not the expected behavior.
Here the MiroTalk SFU host protection logic.
Better would be OIDC or LDAP support because usernames and passwords stored in config files is sooo .......
@imc67 MiroTalk does not utilize a persistent database except for the room scheduler within the MiroTalk WEB application. Within the MiroTalk Selective Forwarding Unit (SFU) configuration, there are options available to verify the validity of usernames and passwords through an API endpoint. By default, this endpoint is set to MiroTalk WEB but disabled. However, you have the flexibility to modify this endpoint to connect to your own database.
Below is the code snippet utilized to check users:
async function isAuthPeer(username, password) { if (hostCfg.users_from_db && hostCfg.users_api_endpoint) { try { const response = await axios.post(hostCfg.users_api_endpoint, { email: username, password: password, api_secret_key: hostCfg.users_api_secret_key, }); return response.data && response.data.message === true; } catch (error) { log.error('AXIOS isAuthPeer error', error.message); return false; } } else { // Check if the user is valid based on the locally stored user credentials return ( hostCfg.users && hostCfg.users.some((user) => user.username === username && user.password === password) ); } }Cheers,
Miroslav@MiroTalk said in participants have to authanticate even with user_auth: false:
@avatar1024 I will verify this as it is not the expected behavior.
Thank you for looking into it! Indeed according to the logic described in the doc (which I had read before trying) this is not what I expect should happen.
-
@avatar1024 I will verify this as it is not the expected behavior.
Here the MiroTalk SFU host protection logic.
Better would be OIDC or LDAP support because usernames and passwords stored in config files is sooo .......
@imc67 MiroTalk does not utilize a persistent database except for the room scheduler within the MiroTalk WEB application. Within the MiroTalk Selective Forwarding Unit (SFU) configuration, there are options available to verify the validity of usernames and passwords through an API endpoint. By default, this endpoint is set to MiroTalk WEB but disabled. However, you have the flexibility to modify this endpoint to connect to your own database.
Below is the code snippet utilized to check users:
async function isAuthPeer(username, password) { if (hostCfg.users_from_db && hostCfg.users_api_endpoint) { try { const response = await axios.post(hostCfg.users_api_endpoint, { email: username, password: password, api_secret_key: hostCfg.users_api_secret_key, }); return response.data && response.data.message === true; } catch (error) { log.error('AXIOS isAuthPeer error', error.message); return false; } } else { // Check if the user is valid based on the locally stored user credentials return ( hostCfg.users && hostCfg.users.some((user) => user.username === username && user.password === password) ); } }Cheers,
Miroslav@MiroTalk said in participants have to authenticate even with user_auth: false:
I will verify this as it is not the expected behavior.
Have you been able to reproduce this? Or any clues what the problem might be?
Many thanks
-
A avatar1024 referenced this topic on
-
@avatar1024 I will verify this as it is not the expected behavior.
Here the MiroTalk SFU host protection logic.
Better would be OIDC or LDAP support because usernames and passwords stored in config files is sooo .......
@imc67 MiroTalk does not utilize a persistent database except for the room scheduler within the MiroTalk WEB application. Within the MiroTalk Selective Forwarding Unit (SFU) configuration, there are options available to verify the validity of usernames and passwords through an API endpoint. By default, this endpoint is set to MiroTalk WEB but disabled. However, you have the flexibility to modify this endpoint to connect to your own database.
Below is the code snippet utilized to check users:
async function isAuthPeer(username, password) { if (hostCfg.users_from_db && hostCfg.users_api_endpoint) { try { const response = await axios.post(hostCfg.users_api_endpoint, { email: username, password: password, api_secret_key: hostCfg.users_api_secret_key, }); return response.data && response.data.message === true; } catch (error) { log.error('AXIOS isAuthPeer error', error.message); return false; } } else { // Check if the user is valid based on the locally stored user credentials return ( hostCfg.users && hostCfg.users.some((user) => user.username === username && user.password === password) ); } }Cheers,
Miroslav@MiroTalk said in participants have to authenticate even with user_auth: false:
By default, this endpoint is set to MiroTalk WEB but disabled. However, you have the flexibility to modify this endpoint to connect to your own database.
@staff is it technically feasible to connect MiroTalk SFU to the Cloudron users database for authentication? Manually creating user and and password in the config file is not very convenient and doesn't feel very secure.
-
This would require some kind of LDAP or OpenID integration on MiroTalk side, which I think does not exist. Depending on if @MiroTalk would be interested, we could see if we can contribute this.
Still I am not 100% sure if all this rather belongs to the MiroTalk Web scheduler instead https://github.com/miroslavpejic85/mirotalkwebrtc
-
@MiroTalk said in participants have to authenticate even with user_auth: false:
I will verify this as it is not the expected behavior.
Have you been able to reproduce this? Or any clues what the problem might be?
Many thanks
@avatar1024 said in participants have to authenticate even with user_auth: false:
@MiroTalk said in participants have to authenticate even with user_auth: false:
I will verify this as it is not the expected behavior.
Have you been able to reproduce this? Or any clues what the problem might be?
Many thanks
@MiroTalk With the latest stable version 1.4.14 the logic still doesn't work as expected, the setting below makes also the participants to have a username / password:
host: { protected: true, user_auth: false, -
So it seems that
protectedanduser_authare mostly covering the same things for the case where mirotalk web is not used as a scheduler.This means if
protectedis false butuser_authtrue, then the login is shown while joining the room, while ifprotectedis true, the login is shown before creating the room.In both cases users have to authenticate.
Maybe we need more info from @MiroTalk here on the intended behavior or if one value only makes sens together with mirotalk web scheduler.
-
So it seems that
protectedanduser_authare mostly covering the same things for the case where mirotalk web is not used as a scheduler.This means if
protectedis false butuser_authtrue, then the login is shown while joining the room, while ifprotectedis true, the login is shown before creating the room.In both cases users have to authenticate.
Maybe we need more info from @MiroTalk here on the intended behavior or if one value only makes sens together with mirotalk web scheduler.
@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 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.
-
@avatar1024 said in participants have to authenticate even with user_auth: false:
@MiroTalk said in participants have to authenticate even with user_auth: false:
I will verify this as it is not the expected behavior.
Have you been able to reproduce this? Or any clues what the problem might be?
Many thanks
@MiroTalk With the latest stable version 1.4.14 the logic still doesn't work as expected, the setting below makes also the participants to have a username / password:
host: { protected: true, 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.
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.
-
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)âŚ..
@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.
