search

DamonOehlman / freeice

Get free, randomized STUN and TURN servers for your WebRTC application
MIT License
289 stars 58 forks source link

authenticated turn servers #13

Open yocontra opened 9 years ago

yocontra commented 9 years ago

https://gist.github.com/yetithefoot/7592580

the way this library works currently doesn't allow for objects to be put in the turn server file, only strings which means usernames and passwords cant be used

DamonOehlman commented 9 years ago

Yeah, that needs to be addressed. I'd still like to use a terse format for defining servers that are an option but I'm not sure what that looks like yet. If you've got any ideas...

yocontra commented 9 years ago

@DamonOehlman Could use a regular expression to grab the username and password from the string, ie

username:password@whatever.com:someport

DamonOehlman commented 9 years ago

Or just pipe separate them, e.g:

whatever.com:someport|username|password

The 0 part is always the host and perhaps in the event that a turn server has no credentials supplied you can have an authentication process for that particular domain. The rtc.io packages do support asynchronous creation of credentials, although it's not well documented at this stage, but it could definitely work.

piranna commented 4 years ago

Isn't this already being fixed with normalice?

DamonOehlman commented 4 years ago

@piranna I think you are right, as long as the URLs were formatted appropriately it should definitely work. From looking at the tests in normalice I think I can do better to make things clear about what it does and also update the README so I'll look at doing that and then we can potentially close this issue.

piranna commented 4 years ago

@piranna I think you are right, as long as the URLs were formatted appropriately it should definitely work. From looking at the tests in normalice I think I can do better to make things clear about what it does and also update the README so I'll look at doing that and then we can potentially close this issue.

That would be great :-)

DamonOehlman commented 4 years ago

@piranna So after checking it is true that normalice has some ability to transform a TURN url into a usable object, however, once I dug into it I can see the issue with the TURN servers that are listed in that gist. They both use a colon delimiter in the username (28224511:1379330808) which means the current : separated syntax that normalice uses to parse things falls over.

In truth, normalice is going a bit beyond it's original mission by even doing any of that as the only reason I think I wrote it was to help ease the transition between the { url: 'server' } format and the newer { urls: ['server'] } format (I'm having to remember back a bit now).

I think the best thing I can do, is to make some reasonably simple modifications to freeice and just allow objects to be specified for turn servers. There's some other modifications that I will make while I'm there also which should make it much more "modern webstack friendly" too.

piranna commented 4 years ago

What about using URL.parse()?

DamonOehlman commented 4 years ago

I suspect that will fail also (not sure though). Did you have turn server urls that you were going to provide? If so, without giving the actual urls away is there a format you were hoping to use?

DamonOehlman commented 4 years ago

As an aside here's another gist with a big list of servers:

https://gist.github.com/sagivo/3a4b2f2c7ac6e1b5267c2f1f59ac6c6b

piranna commented 4 years ago

I suspect that will fail also (not sure though). Did you have turn server urls that you were going to provide? If so, without giving the actual urls away is there a format you were hoping to use?

URL.parse() can identify both usernames, passwords and schemas, so it should work. Anyway, schemas are only turn:, stun: and turns: (this one currently not supported), so it's easy to identify them...

As an aside here's another gist with a big list of servers:

This is HUGE! :-D Would love to have them inside freeice. Maybe a tool that checks their availability nightly would be needed thought, to don't have them out of sync.