Is there a maximum limit of client credentials my control integration can use ?
I would like to control the sonos devices via a small IOT device that has it's own event callback URL without using an external server.
Is this possible ?
In the client credentials I can only configure one event callback url.
I would build a tiny webservice in the IOT device that receives event callbacks for status changes. (Volume changes / Playback states / group states)
Every IOT device needs a different callback url (and different client credentials).
Is this possible ?
If this is possible can we use a self-signed certificate for our IOT webservice ?
Is there a maximum limit of client credentials my control integration
can use?
There's no maximum limit. But note that your application uses the API key and secret, not the customer, therefore you should not need more than one. You don't need to create a unique API key and secret for each customer. You may need to create multiple credentials if you wish to have a one for your development app and one for your production app.
I would like to control the sonos devices via a small IOT device that
has it's own event callback URL without using an external server. Is
this possible?
We do not currently support a redirect URI to a local device or app (for example - a Redirect URI that opens an app on the device).
Related
I have a web application with e.g 1...n users. User(s) logs in use application and logs out.
Now How to achieve if a logged in user say User "A" want to video chat with User "B"?
Does WebRTC shares a sessionId etc to identify which user is sending request and how this request is for specific set of users (Receivers would be only "B" User) ?
No, WebRTC does not provide this kind of authorization. That's because WebRTC relies on an external signaling system.
This kind of authorization you must include it in your signaling system. E.g. if you're using websockets you can use the session from there to authorize, identify and route the message to the appropriate user. And that will depend of course on what platform/technology you're using on the server side.
I am testing a server that uses google cloud messaging (GCM)
In order to perform the test without an actual device (for a faster way and actually test only the server side)
I am looking for a way to register as a client WITHOUT a device
I have from the server the project id and the sender id
But I see that I need an instanse id of the client in order to register to GCM (via https: //android.googleapis.com/gcm/send)
Is it possible to generate an instance id without an actual client?
P.S.
Maybe it will help I have found this code of Angular GCM client, and Python GCM client
but i couldn't succeeded to find a solution for registration yet
Thank you
I don't think you can remove the "client app" out of the equation as it is part of the architectural components of GCM:
A GCM implementation includes a Google connection server, an app
server in your environment that interacts with the connection server
via HTTP or XMPP protocol, and a client app.
However if you meant, without a real device, try using the emulator.
I'd like to know if each time my application runs I need to get the token and pass it to the server, or if it's only necessary once to register the application. Thanks a lot.
You need a token to register the GCM(push notification) to the Google Server. Then this token is passed and used in the server to send subsequent notification. This token should be persisted by the server so that it can be used to make API calls to the Google server. With this approach, your server and the Android device do not need to create a persistent connection and the responsibility of queuing and relaying messages is all handled by Google's servers.
For more information visit the Registering Client Apps and also check this documentation.
We're trying to find a way to authenticate a client via a mobile application rather than using a captive portal splash page. Is this possible at all?
I've looked at the CloudTrax API but can't seem to find anything that directly indicates the ability to authenticate users.
Another option I considered was trying to make a http request which would return the splash page and then with Javascript, imitate a click event on the authenticate button..
If you use the cloudtrax http authentication then you should be able to do this fairly easily.
Cloudtrax HTTP auth sends an initial status request to your HTTP auth endpoint whenever a client connects to the wifi network if they haven't already got an authenticated session. This is before any login or captive portal popup is displayed. Your HTTP endpoint can respond to that request with an ACCEPT message along with session time and bandwidth restrictions. The AP will then just authenticate the device and allow it internet access without displaying any captive portal.
Not sure what your use case is for the mobile app (eg are you doing some other customer engagement inside the app?), but you could implement this without an app. Just push them to a captive portal the first time you detect their mac address, get them to register. Then all future connections can just be automated in the backend.
If you do need an app, then just do the registration part inside the app and have the app send their mac address to your backend server so the HTTP auth server can look it up in future.
I'm building an application which uses last.fm API. I want my server to communicate with last.fm and the users of my application would communicate with the server. So the user is indirectly communicating with last.fm. I'm doing this to speed up the whole communication by caching some data on my server.
Is this OK?
As long as you follow their TOS, you are OK.
Yes, this is OK. Many other services do this.
If you think about it, any action any app takes is always indirect. There is no requirement that the application acting on behalf of the user runs on the same computer as the user. Quite often the application runs on a web server.
Some examples of apps which do this include http://tweekly.fm/ and http://hypem.com/ .
In order for the service to act on the user's behalf (for certain methods such as scrobbling), you have to authorise your application as the user, and this is achieved using the web auth flow described at http://www.last.fm/api/webauth .
(This is one of those flows where the user is directed to a page on Last.fm to confirm that they authorise your app. Your app receives a session key in return, which allows your app to act on behalf of the user).