Authorized Connection

[alexsluch]

Hi guys, thanks for your job=)
However, how can I use login / password or better access_token for authentication on signal server?

[devluz]

The signaling server itself doesn't handle login/ passwords. This is a large task by itself and should be handled separately. Once a user has permission to access the server you could share an access token and check it in the request here:

https://github.com/because-why-not/awrtc_signaling/blob/master/WebsocketNetworkServer.ts#L122

Do you have any specific systems / libraries in mind to handle the login?

[alexsluch]

The signaling server itself doesn't handle login/ passwords. This is a large task by itself and should be handled separately. Once a user has permission to access the server you could share an access token and check it in the request here:

https://github.com/because-why-not/awrtc_signaling/blob/master/WebsocketNetworkServer.ts#L122

Do you have any specific systems / libraries in mind to handle the login?

I want the signaling server access to be restricted to authorized users only. I'm creating something like a telephone service where one user can call another, but I want to limit the ability for others to connect using checks. That is, only users registered on my server can access the signaling server. Additionally, only two users (the one creating the room and the one for whom the room is created) can connect to the signaling server. I'm looking for ways to implement this task. So far, what I've come up with is using a special generation of room names, and having Nginx on the signaling server to receive data, process it, check availability, and if it's okay, then perform a redirect to the signaling server. However, this seems too complicated; it would be better if the signaling server itself could handle this.

[devluz]

In most projects the signaling server is just a small puzzle piece in a larger project. I don't think it makes sense for it to decide how to manage users or how login works. These are decisions that will be different for every application.

e.g. A more complex system might work like this:

1. You have an application specific server that includes WebsocketNetworkServer.ts or the two run separately in parallel
2. Alice & Bob log into the application specific server. It can handle friend lists, rooms, push notifications or any other features your specific application needs
3. Once Alice and Bob triggered something in your server (like starting a video chat) then the application server creates an address / passphrase (just a random token). This is shared along side with the signaling server address.
4. Alice and Bob now both connect to the signaling server with your token and use it in the ICall.Listen / ICall.Connect methods
5. The signaling server is then used to exchange their connection information, ensuring cross platform compatibility and compatibility to versions of WebRTC Video Chat
6. The signaling server connection is cut once the two users are connected directly while your app server connection likely remains to handle other tasks

Step 1-3 will be very different for each application e.g. one might be a 3D game that connects users when they are physically near each other and the next just connects all users using the same server or let the user decide each individual connection.

What platforms and devices do you plan to target with your client side application? How do your users register and get authorised to access your server? What I could do is create a more advanced example in a separate repository that might give some starting point for this.

[alexsluch]

In most projects the signaling server is just a small puzzle piece in a larger project. I don't think it makes sense for it to decide how to manage users or how login works. These are decisions that will be different for every application.

e.g. A more complex system might work like this:

1. You have an application specific server that includes WebsocketNetworkServer.ts or the two run separately in parallel
2. Alice & Bob log into the application specific server. It can handle friend lists, rooms, push notifications or any other features your specific application needs
3. Once Alice and Bob triggered something in your server (like starting a video chat) then the application server creates an address / passphrase (just a random token). This is shared along side with the signaling server address.
4. Alice and Bob now both connect to the signaling server with your token and use it in the ICall.Listen / ICall.Connect methods
5. The signaling server is then used to exchange their connection information, ensuring cross platform compatibility and compatibility to versions of WebRTC Video Chat
6. The signaling server connection is cut once the two users are connected directly while your app server connection likely remains to handle other tasks

Step 1-3 will be very different for each application e.g. one might be a 3D game that connects users when they are physically near each other and the next just connects all users using the same server or let the user decide each individual connection.

What platforms and devices do you plan to target with your client side application? How do your users register and get authorised to access your server? What I could do is create a more advanced example in a separate repository that might give some starting point for this.

Hello,

I am currently using your Unity plugin for Android and iOS, with a main server running on Python, which uses a login and password to generate a token for interacting with the main server. As I understand, if your signaling server's server-side implementation is available, the Unity client version is closed for modification. I agree with and support your idea, but the question remains open—how to transmit the authorization token to the signaling server and how to conduct the verification. We could preliminarily agree on a method of encrypting the token to avoid setting up a direct link between the signaling and the main server, but the question of the token's acceptance and transmission by the signaling server remains unresolved.

I would be grateful for a more detailed example, especially since I have not worked with Node.js before.

Looking forward to your suggestions or guidelines on this matter.

[devluz]

Ok I think I understand. With a python server it will be a bit more difficult. How about we do this with two tokens and a REST API call then:

admin token: Allows access to a REST API to setup user tokens (for other servers)
user token: allows access to the signaling / websocket protocol by appending the user token to the signaling URL

Usage might look like this:

1. During setup of the signaling server you set an admin token in the config.json and you share that token with your python server
2. When a user needs to access the signaling server it will first communicate with your python server to get an user token
3. Your python server calls a rest api call SetUserToken with the admin token, a new string to use as user token and a timeout value in seconds
4. The signaling server returns a 200 OK to your python server
5. Python server shares the user token with your user / unity client
6. The unity client now connects the the signaling server but appends the token to the signaling URL (e.g. appending "?usertoken=1234"
7. Signaling works as usual but if the token is past its timeout or invalid the server would block a connection

Tokens are just strings for the signaling server so you can decide the details of them or reuse existing ones from python.

Would that work for you? That seems like a useful addition to the server that is flexible enough for all use-cases. This change would also not require patching any of the other platforms. Just a server side is needed.

[alexsluch]

Ok I think I understand. With a python server it will be a bit more difficult. How about we do this with two tokens and a REST API call then:

admin token: Allows access to a REST API to setup user tokens (for other servers) user token: allows access to the signaling / websocket protocol by appending the user token to the signaling URL

Usage might look like this:

1. During setup of the signaling server you set an admin token in the config.json and you share that token with your python server
2. When a user needs to access the signaling server it will first communicate with your python server to get an user token
3. Your python server calls a rest api call SetUserToken with the admin token, a new string to use as user token and a timeout value in seconds
4. The signaling server returns a 200 OK to your python server
5. Python server shares the user token with your user / unity client
6. The unity client now connects the the signaling server but appends the token to the signaling URL (e.g. appending "?usertoken=1234"
7. Signaling works as usual but if the token is past its timeout or invalid the server would block a connection

Tokens are just strings for the signaling server so you can decide the details of them or reuse existing ones from python.

Would that work for you? That seems like a useful addition to the server that is flexible enough for all use-cases. This change would also not require patching any of the other platforms. Just a server side is needed.

look like awesome)

[devluz]

I pushed a way to use tokens: https://github.com/because-why-not/awrtc_signaling/blob/master/README.md
Just watch out there were a few major internal changes I also pushed. The file structure as changed to look more like a modern typescript project.

[alexsluch]

I pushed a way to use tokens: https://github.com/because-why-not/awrtc_signaling/blob/master/README.md Just watch out there were a few major internal changes I also pushed. The file structure as changed to look more like a modern typescript project.

Thanks a lot!