Parse openvidu's "token" into useful object and json

[banagale]

Description

Currently openvidu's api token response is a websocket URI containing useful information like the actual token string and role.

This would likely be more useful if parsed into a dictionary and/or object.

Suggested solution

def parse_ov_token(token_uri: str) -> Tuple[dict, str]:
    """
    openvidu returns a "token" in the form of wss:// URI.
    This function parses that into an object and json format
    """
    # Parse URI into dictionary
    token = urllib.parse.parse_qs(urllib.parse.urlparse(token_uri).query)
    value: List
    for key, value in token.items():  # Convert values from list to strings
        token[key] = value[0]
    return token, json.dumps(token)

Not sure if this is a problem for anyone else, but it seems odd to me that the openvidu api returns a URI as a token response in the first place.

[banagale]

I just realized after re-consulting the ov docs for POST /api/tokens, OV does return a dictionary, and that perhaps pyopenvidu just needs to return that.

This line could instead just return the response. 

Is there a particular reason it currently returns the URI?  This would be a potentially breaking change, but it seems like the default should be a dict.

[marcsello]

Well there are a few reasons behind this solution:

• All information returned by the API are the same as the information being posted + the token, so there is nothing new in that dict.
• Every object (dict) returned by the server are transformed into native Python objects for various reasons described bellow. So no function returns the raw dict the server provides (except get_config). So this would be inconsistent and confusing for developers.
• In my dictionary the "token" is that websocket URI. So it seamed reasonable to me to return with only that.

If you feel like this does have a valid use-case a proper solution would be creating a "OpenViduToken" object (similar to OpenViduConnection for example) which provides getters for all properties in the dictionary returned.

The reason behind using Python data objects instead of raw dicts is that IDEs are able to discover it, and provide useful autocompletion. Along with that it's so much easier to document the library so that developers have to read only one documentation while using this library instead of both the OpenVidu API Docs and the docs of this lib. Another reason is that this library is capable of providing a stable interface whereas OpenVidu sometimes changes their API without properly documenting it. So projects built on this library does not have to change their code every time the API is changed.

[banagale]

• All information returned by the API are the same as the information being posted + the token, so there is nothing new in that dict

This is a key point, it is not really useful to get much more than a confirmation that what was posted was what was associated with the returned, new token.

Pyopenvidu's consistent use of python data objects rather than dicts are fine and make good sense as you've explained it.

I was drawing attention to the dictionary more because it offers structured data rather than all of it embedded in the URI.  

I see that OV has the sample return data as:

{
  "id": "wss://localhost:4443?sessionId=zfgmthb8jl9uellk&token=lnlrtnkwm4v8l7uc&role=PUBLISHER&turnUsername=FYYNRC&turnCredential=yfxxs3",
  "session": "zfgmthb8jl9uellk",
  "role": "PUBLISHER",
  "data": "User Data",
  "token": "wss://localhost:4443?sessionId=zfgmthb8jl9uellk&token=lnlrtnkwm4v8l7uc&role=PUBLISHER&turnUsername=FYYNRC&turnCredential=yfxxs3",
  "kurentoOptions": {
    "videoMaxSendBandwidth": 700,
    "allowedFilters": [
      "GStreamerFilter",
      "ZBarFilter"
    ]
  }
}

So even though OV returns structured data, the token is still embedded inside the websocket URI, strangely called, 'token.'   It seems like this should be 'wssUri' and a separate parameter should be given for 'token' which is in the above example, `lnlrtnkwm4v8l7uc`

I have not fully implemented OV yet, but had expected I would need to be handling the token directly. 

For example, in the openvidu-call-react app it uses the actual token string to make the connection to the session.

I'm not sure how to provide that to the frontend without first parsing the URI into components to get at that string. 

Perhaps I'm missing something here. But my point was that if someone is trying to build a private API to link a python-based web app auth system up with the perms necessary to generate tokens it will need to get at this token string and make it available to the frontend.

Edit: This is really a question for OV, I think I went ahead and posted it in their forum.

[banagale]

So, I got feedback in that thread that OpenVidu does expect a full websocket URI as the token.

I added an issue for this to get a bit better docs here: OpenVidu/openvidu.io-docs#39.

I think this invalidates this issue. Thanks for the engagment.