Hi all. The newer codebase has broken a lot of functionality I had developed and I’m trying to get my system operational again.
The old documentation had an example of how to stream the android instance (now archived here: Set up a stream client). It would be of great help if there was a similar example of how to do this using the new API/codebase. Does anything like this exits? The existing documentation is a bit too abstract for me to know how to best implement.
I previously accessed the streams using a constructors like this - does something like this exist for the new API?
Available Commands:
buginfo Collection information for effective bug reports
completion Generate the autocompletion script for the specified shell
config Managed the Anbox Cloud Appliance configuration
daemon Run the Anbox Cloud Appliance daemon
dashboard Manage the dashboard of the Anbox Cloud Appliance
help Help about any command
init Initialize and configure the Anbox Cloud Appliance
prepare-node-script Generate a shell script to prepare a machine for the Anbox Cloud Appliance
status Retrieves the current status of the Anbox Cloud Appliance
However, I found that this functionality exists in a separate application
/snap/bin/anbox-cloud-appliance.gateway
I’m curious if there is an issue with my install or if this is a bug?
I am sorry to hear something broke for you. If you had an existing deployment of Anbox Cloud or the Anbox Cloud Appliance, nothing should have broken. If you had a pre-1.23 version of the Anbox Cloud Appliance deployed you should still have the exact same setup as before. Only if you have been installing the appliance fresh from 1.23 on wards you should see the changed behavior.
The new version (>= 1.23.0) of the Anbox Cloud Appliance does not expose the stream gateway API on the public HTTPS endpoint anymore for improved security. You can still access the stream gateway from within your deployment and that is what you need to do. The gateway API is not meant to be accessed from the outside, except the signaling endpoint, as it is required for WebRTC to function. Encoding the auth token in a website is not going to be really secure and is only meant to be used in a safe and controlled environment for development / testing use cases.
Glad to hear this shed some light and have helped.
Yes, the streaming SDK still works but you either need to frontend the gateway API with your own API service and implement a connector component (see here).
The tutorial is not ready yet, but we have an e2e test here which may help you to understand how to implement this until the tutorial is ready. Especially server.js and index.html are the relevant parts here.
Thank you for the prompt reply. In my setup, I am spinning up new appliance servers and configuring them individually, which is why I’m now on 1.23. Is there a way to force-install the older version? That would make my life infinity easier as I’ve spent a lot of time trying to get the existing functionality working again with the new infrastructure.
It would also be ideal to lock in a version and be able to control when it gets upgraded so as to avoid breaking changes being applied automatically.
I totally understand the security concerns, but in my setup, everything is tunneled which requires an additional layer of authentication and I feel that it provides adequate security for my use case. Would it be possible to use iptables to port forward the stream gateway and be able to use the existing codebase as an option?
Thank you for pointing out the e2d test. If I’m to understand it correctly, is this how it operates:
The same AnboxStream() object is used in the same way as before, but the connector is custom and implemented in the server.js by way of the request to /join
server.js only needs to make the call to /1.0/sessions//join and forward the response back to the AnboxStream() by way of this struct
As long as index.html is given the ‘sessionId’, tha’ts all that needs to happen? And the rest of server.js implements an additional API that’s for searching through instances, etc. but not necessary for streaming. As long as I have the sessionId, then I can generate a stream? (i.e. only the /join function is required for streaming)
Are there any additional steps required to enable the stream beyond what was required pre 1.23?
And can I just specify ‘*’ for the CORS settings to make my life easier?
After some experimenting, I was able to get the new API working. Just some constructive feedback - the documentation seems to either be at a very low level most of the time, or at a very high level. Your responses and the example code helped me bridge the two. Thanks again.
Though now I have a security question. Once I provide the user with the websocket and the turn server information, doesn’t that given them access to the android application whenever they want? Prior, I would delete the gateway token to keep them from accessing it - but how do I do so now?
And is there any need to implement the additional API interfaces beyond just /join?
you can install the old version again. Switching to version specific channel also allows you to stay on exactly that version for as long as you want without being automatically updated. See https://snapcraft.io/docs/channels for more information on what channels are and how they can be used.
The TURN credentials are only valid for a very short amount of time and can then no longer be used. The same applies for the signaling URL the gateway returns from the /joinAPI endpoint.
If you provide an actual token for the stream gateway API to your users, you give them wide open access to the entire API until you revoke access. In neither case you should do that as users will be able to create additional sessions or delete other users ones. The gateway API is really only meant for internal use and should not be exposed, which is the primary reason we limit access in the new appliance. For large deployments we always advise users to put a web application firewall (e.g. AWS WAF) in front of the gateway to limit API exposure. In a future version of Anbox Cloud we will move of the API functionality to the AMS API endpoint and remove what should not be public exposed from the gateway one.
No, unless you have very specific needs.
The example is an e2e test implementation which has additional functionality not needed in your case. A general good advise is to keep only features you really need.
The security impact is that you make access wide open. For production or any public exposed endpoints this is not recommended.
In my current setup, I spin up a server and run a bash script to install all relevant packages and the anbox-cloud-appliance. I then use this command to spin up an instance
When I try to use my code to connect to the streaming gateway, it doesn’t work and seems as if the websocket is not returning anything. Then, if I go to the dashboard, I see the instance that I created and can view it just fine. If I go then back to my code and try it again, it works just fine. It’s as if I’m missing some critical initialization that the dashboard is doing?
Is there some other sort of initiation that happens by the dashboard that I would need before I can connect to my instance?
I also want to avoid registering my user with the dashboard through ubuntu-one as I’ve not found a way to do that programmatically without having to go through the wepage gui – could that be what’s required to enable the streaming server?
Was the websocket connection actually established? You can use the dev tools in a Chrome / Firefox browser to verify that. If you access the dashboard and then it works it might be related to self signed certificates and trust you establish for them within your browser?
There is nothing really special the dashboard does, you can actually find a preview of an upcoming tutorial we have in the works here which implements things in a similar way as the dashboard does. This will allow you to compare with what you currently have.
No, that’s really just specific to the dashboard and is not relevant if you access the stream gateway API directly. I recommend taking a look at the tutorial I linked above and see if that helps as without much more insight into your code or knowing how it works, it’s hard for us to determine what is wrong.
You were right. The issue has to do with the certs. The best solution that I can come up with is to proxy the connections through a server with a Let’s Encrypt cert, though I’m making slow progress with that approach. I just got it working!
Alternatively, is it possible to downgrade from wss:// to ws:// so as to avoid the cert issue?