REST API Issue

[Palmtown]

Hello,

I've read over dozen topics all having the same issue, not able to get the REST API working in hope to resolve my problem.  Unfortunately, after all that reading and testing, still not able to get it to work.  Below I have listed my setup; if you have knowledge of what's wrong, your comments are much appreciated:

Snapshot of configuration

#lt-cred-mech

#no-auth

use-auth-secret

mysql-userdb="host=localhost dbname=turn user=turn password=turn port=3306 connect_timeout=30"

fingerprint

How am I generating key?

PHP:  base64_encode(hash_hmac("sha1", "myuser", "mysecret", true)); Reference:  http://php.net/manual/en/function.hash-hmac.php

Test Command

turnutils_uclient -v -u 1480315314:myuser -W kwJYOcHMkzEhoWwzfv07/4cCFHM= localhost

Results:

No matter what key or user I provide, I am getting the same results, it seems to connect regardless of anything I use.  However, I have no clear indication if it is successful or not as if I use the above combination in the actual WebRTC client, it doesn't appear to be working.  The only thing that appears to work is if I use lt-cred-mech and add the username/password in the web admin, and that works for the web client.  

0: IPv4. Connected from: 127.0.0.1:60191

0: IPv4. Connected to: 127.0.0.1:3478

0: allocate sent

0: allocate response received:

0: success

0: IPv4. Received relay addr: 22.22.22.22:64218

0: clnet_allocate: rtv=8138178124944373244

0: refresh sent

0: refresh response received:

0: success

0: IPv4. Connected from: 127.0.0.1:42196

0: IPv4. Connected to: 127.0.0.1:3478

0: IPv4. Connected from: 127.0.0.1:60327

0: IPv4. Connected to: 127.0.0.1:3478

0: allocate sent

0: allocate response received:

0: success

0: IPv4. Received relay addr: 22.22.22.22:64219

0: clnet_allocate: rtv=0

0: refresh sent

0: refresh response received:

0: success

0: allocate sent

0: allocate response received:

0: success

0: IPv4. Received relay addr: 22.22.22.22:62972

0: clnet_allocate: rtv=11576298126837407115

0: refresh sent

0: refresh response received:

0: success

0: channel bind sent

0: cb response received:

0: success: 0x526e

0: channel bind sent

0: cb response received:

0: success: 0x526e

0: channel bind sent

0: cb response received:

0: success: 0x413d

0: channel bind sent

0: cb response received:

0: success: 0x413d

0: channel bind sent

0: cb response received:

0: success: 0x6b25

0: Total connect time is 0

1: start_mclient: msz=2, tot_send_msgs=0, tot_recv_msgs=0, tot_send_bytes ~ 0, tot_recv_bytes ~ 0

2: start_mclient: msz=2, tot_send_msgs=0, tot_recv_msgs=0, tot_send_bytes ~ 0, tot_recv_bytes ~ 0

3: start_mclient: msz=2, tot_send_msgs=0, tot_recv_msgs=0, tot_send_bytes ~ 0, tot_recv_bytes ~ 0

[Oleg Moskalenko]

It looks like your TURN server is configured without authorization. It
allows clients without authorization.

Is that possible that the server does not see the correct configuration file ?

Did you configure the realm ?

I just tested everything with the latest coturn release, it works as expected.

Look at the scripts in the directory examples/scripts/restapi. Those
are examples how to configure the REST API functionality.

Oleg

On Sat, Nov 28, 2015 at 3:55 PM, 'Palmtown' via TURN Server
(Open-Source project)

> --
> You received this message because you are subscribed to the Google Groups
> "TURN Server (Open-Source project)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to
> turn-server-project-rfc57...@googlegroups.com.
> To post to this group, send email to
> turn-server-project...@googlegroups.com.
> Visit this group at
> http://groups.google.com/group/turn-server-project-rfc5766-turn-server.
> For more options, visit https://groups.google.com/d/optout.

[Palmtown]

Hello Oleg,

Note that I am using Cent OS 7 with configuration as shown below.  Also, note that my realm is set in the configuration file.  Another thing I observed is that it allows open authentication whenever I set comment #lt-cred-mech.  If I uncomment lt-cred-mech and use-auth-secret at the same time, then I get the error "heck_stun_auth: Cannot find credentials of user <1448865729:1480315314:myuser>" every time.  It is picking up the configuration file fine as I can change different things in the configuration file and it will apply it.   Lastly, note my case is similar to https://groups.google.com/forum/#!searchin/turn-server-project-rfc5766-turn-server/rest$20api/turn-server-project-rfc5766-turn-server/7FS_fnXQ1oU/Sr33_owKkWUJ in that no matter what is given, it stills seems to be successful.  However, when implemented in WebRTC it only works sometimes. 

The only case I can get it to work is when lt-cred-mech is uncommented, and #use-auth-secret is commented and I inserted a user into the database via web console.  Then my WebRTC app is working 100% of the time.  Otherwise, it will not work.    I've tested just about all case in the scripts folder.  But I'm getting the same outcome.  What is odd, is that when I set the 2 options it-cred-mech and use-auth-secret no matter what I give in the util command line, it always "appears" to be successful.

uname -a

Linux ip-172-31-2-132 3.10.0-229.20.1.el7.x86_64 #1 SMP Tue Nov 3 19:10:07 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

configuration file location

/etc/turnserver/turnserver.conf

[Palmtown]

Hello Oleg,

In addition to my last reply, note that I am also using the install for CentOS 7.1 from http://turnserver.open-sys.org/downloads/v4.5.0.3/turnserver-4.5.0.3-CentOS7.1-x86_64.tar.gz.  

[Oleg Moskalenko]

I do not know what to say. Something is not right. I suspect something
is not right in your turnserver.conf formatting. Because I just tried
to this kind of configuration and it works fine.

I know that the scripts in restapi directory work 100%.
Then I suggest the following sequence of actions:

1) Try to configure it thru the command-line only (remove the
turnserver.conf completely). Make sure that it works.
2) Add turnserver.conf with all lines commented out. Check that it works.
3) Start uncommenting the relevant configuration lines in
turnserver.conf and removing them from the command line options. Do it
one-by-one option. Let me know the result of the process. If there is
a problem with options handling, this process must reveal it.

Thanks
Oleg




On Sat, Nov 28, 2015 at 10:52 PM, 'Palmtown' via TURN Server
(Open-Source project)

[Palmtown]

Hello Oleg,

After hours of research and testing, I was able to figure out the problem.  I come to find the common problem is documentation as other users have experienced as it can be misleading.  Also, I found a few replies by you that were incorrect and I wanted to point that out as well.

First, when running the command turnutils_uclient as outlined on https://code.google.com/p/rfc5766-turn-server/wiki/turnutils_uclient, one needs to specify the "plain text" secret that is in the value field of the database, or set in the configuration file for the variable static-auth-secret.  For example, if "north" is in the database or static-auth-secret=north, then the command would be:

turnutils_uclient -v -u myuser -W north localhost

The misconception is is that on https://code.google.com/p/rfc5766-turn-server/wiki/turnutils_uclient it doesn't vividly explain that the -W option should be plain text as I have described it above.  I would recommend you to copy and replace the text as given below which will give users an exact understanding of running the command as this was my first problem.

Secondly, in a previous post I read, you stated that lt-cred-mech is not needed and can be commented out when using use-auth-secret.  However, that is not true.  If you comment out #lt-cred-mech and only uncomment use-auth-secret, then it will allow anonymous authorization which is the issue I experienced and explained previously.  To use the REST API, one must uncomment lt-cred-mech and use-auth-secret, and then only the REST API will work correctly.

Updated to https://code.google.com/p/rfc5766-turn-server/wiki/turnutils_uclient:

• -W <secret> TURN REST API secret. The "plain text" secret e.g. "north" that is in the stored in the value column of the turn_secret table in the database if dynamic, or the static-auth-secret value set in the configuration file if using static.  Note that this option is not compatible with the -A flag.

Lastly, you have associated https://rfc5766-turn-server.googlecode.com/svn/docs/TURNServerRESTAPI.pdf as part of the project which is misleading.  Many users as I have seen mistake this for a feature of CoTurn, however, it is merely referencing an RFC of how the API should function should the user decide to implement it.  I would recommend to only use this as a reference in an instructional document that is in direction relation to CoTurn itself.  

If you need assistance with the project, I would be willing to write this document for you and develop a server-side API to utilize the project provided you will ensure that appropriate credits are provided to me for donating my time.  

Thanks for your hard work.

[Oleg Moskalenko]

Please see below:

On Sun, Nov 29, 2015 at 1:19 AM, 'Palmtown' via TURN Server
(Open-Source project)

<turn-server-project...@googlegroups.com> wrote:
>
> After hours of research and testing, I was able to figure out the problem.
> I come to find the common problem is documentation as other users have
> experienced as it can be misleading. Also, I found a few replies by you
> that were incorrect and I wanted to point that out as well.
>
> First, when running the command turnutils_uclient as outlined on
> https://code.google.com/p/rfc5766-turn-server/wiki/turnutils_uclient, one
> needs to specify the "plain text" secret that is in the value field of the
> database, or set in the configuration file for the variable
> static-auth-secret. For example, if "north" is in the database or
> static-auth-secret=north, then the command would be:
>
> turnutils_uclient -v -u myuser -W north localhost

I never said that it must be anything else than a plain password.
Check the file examples/scripts/restapi/secure_udp_client_with_secret.sh.
It has the plain password. I always recommend checking the example
scripts.

>
> The misconception is is that on
> https://code.google.com/p/rfc5766-turn-server/wiki/turnutils_uclient it
> doesn't vividly explain that the -W option should be plain text as I have
> described it above. I would recommend you to copy and replace the text as
> given below which will give users an exact understanding of running the
> command as this was my first problem.

OK, I'll do that, if it will clarify the things. Thanks for the text.

>
> Secondly, in a previous post I read, you stated that lt-cred-mech is not
> needed and can be commented out when using use-auth-secret. However, that
> is not true.

You are right - that is not true. My intention was to make it as
implied option when the REST API is used, but somehow that
functionality slipped away. I'll fix it in the next build.

> If you comment out #lt-cred-mech and only uncomment
> use-auth-secret, then it will allow anonymous authorization which is the
> issue I experienced and explained previously. To use the REST API, one must
> uncomment lt-cred-mech and use-auth-secret, and then only the REST API will
> work correctly.
>
> Updated to
> https://code.google.com/p/rfc5766-turn-server/wiki/turnutils_uclient:
>
> -W <secret> TURN REST API secret. The "plain text" secret e.g. "north" that
> is in the stored in the value column of the turn_secret table in the
> database if dynamic, or the static-auth-secret value set in the
> configuration file if using static. Note that this option is not compatible
> with the -A flag.
>
> Lastly, you have associated
> https://rfc5766-turn-server.googlecode.com/svn/docs/TURNServerRESTAPI.pdf as
> part of the project which is misleading. Many users as I have seen mistake
> this for a feature of CoTurn, however, it is merely referencing an RFC of
> how the API should function should the user decide to implement it. I would
> recommend to only use this as a reference in an instructional document that
> is in direction relation to CoTurn itself.
>
> If you need assistance with the project, I would be willing to write this
> document for you and develop a server-side API to utilize the project
> provided you will ensure that appropriate credits are provided to me for
> donating my time.

Of course I'll appreciate any help and I'll add your information to
the project credits.

But I'd like you to consider the fact that REST API for TURN is never
is going to make it to and RFC. This is why I am not actively working
on it. On the other hand, the oAuth (third-party authorization) is
being pretty successful in the standardization process, and it seems
to be the future TURN authorization technique. And you can achieve
about the same (but better) result as with REST API.

Coturn supports third-party authorization, but it has no tools to
connect the TURN server to the authorization server - the TURN server
users are supposed to develop that themselves.

I do not mind if you participate in the project by writing REST API
tools, but I think that oAuth-based work may be a better spent time of
yours if you are willing to move into that direction.

But that's totally up to you.

Thanks
Oleg

>
> Thanks for your hard work.
>

[Oleg Moskalenko]

I updated the documentation in the new project page wiki:

https://github.com/coturn/coturn/wiki/turnutils_uclient

I pushed update to the source code to make lt-cred-mech option
'automatic' if the REST API is used. It will be available in 4.5.0.4
build.

Thanks
Oleg