Turnserver compatibility user/password instead static-auth

[Bolli84]

With the current implementation, I did not find any ability to use the login procedure with the turnserver (coTurn, ...) In Talk config mask, only the static-auth is possible, which is actually not a good procedure.

Request: User/pass for the talk setup should be allowed.

Describe alternatives you've considered
N/A

[nickvergessen]

User/Pass is used in the end. The Talk app creates the username and password.
Is that what you mean?

[Bolli84]

When you look into the Settings for Talk, you van enter the turnserver URL and the shared-secret.
With better setup configurations in the turnserver, you need to enter user/pass instead of the simple shared-secret = static-auth.
If you use greatest setups, you cannot use the same turnserver, as most other setup require user/Password.
That should also be possible with talk.

[nickvergessen]

@fancycode maybe you can help to clarify this?

[fancycode]

Username/password for the TURN configuration are valid indefinitely and should only be on a per-user base (see #84 on the initial implementation). As the global TURN credentials are sent to each participant in a call (registered and anonymous), everybody could (ab-)use the credentials to create other connections through the TURN server from other services.

That's why Talk switched to the shared secret TURN configuration and hands out short-lived credentials to users that can not be used indefinitely.

If we allow configuring TURN username/password in the admin settings, it should show a big warning that the credentials will be sent to all participants and therefore must be considered "public". Another option would be to add this to the personal settings similar to what was done in #84 but fallback to the global shared secret setting if a user doesn't configure his own credentials.

[nickvergessen]

Okay, sounds like it is not a good idea, but only to get other turns to work. So not a priority at the moment.

[Bolli84]

It is the same as with the shared secret.
E.g. if you are using a second Implementation on the same turnserver, it has more needs like that. E.g. kurento-media-server

Using username:password of a turnserver user is exactly valid as it is with the currently used static-auth.

[nickvergessen]

Using username:password of a turnserver user is exactly valid as it is with the currently used static-auth.

No the current approach is that every users get's unique custom credentials which expire, while with the fixed static auth, I can copy your turn credentials and server url to my instance after I had a guest call on yours, and then abuse your turn server for my talk calls?

[Bolli84]

Topic can be closed as it is not relevant.