Looking for best practice for an app to connect to a spark device.
I want to make an app that connects to a spark device as seamless as possible. Basically run the app and set the spark device ID and be able to connect right away. (Wifi setup aside).
Is it a good practice to embed in my app (say for iOS) my username and password in order to login to the Ali and get an access token if the one I have in my device is expired or not available?
Doesn’t seem right to store sensitive information on the device or app… Is there another approach on how to handle this?
I am envision I will have multiple devices for multiple clients (persons with an ios App) and those people basically after doing the wifi config of the spark, want to pair with the spark… To pair it I think it will use the spark device ID and go from there to find and talk to the device. Since your tokens expire, I cannot pre program a token on the iOS app and expect it to work forever. I need means to refresh the access token.
I am also assuming that in the “factory” I will have to do a claim of the device. I don’t want my clients setting up an account with spark for their device to work!
How would one handle this?? Is there a best practice or a feature coming that will allow this?
I need multiple apps to pair with multiple devices on one-to-one basis..
So one app can pair to one device by knowing only the device-id... And no one else can pair with him... So the server should allow clients (APPS) to claim a core, and a core can only be claimed once so the app can talk to the core thru the cloud.. Like NEST.. Each thermostat can be associated with one user and that user can have multiple nests...
The question is Right now in order to do this.. I need to give my APP my user credentials so that he can get a security_token and talk to the spark via the cloud.
NEST does not embed system wide username/pass in the app in order to be able to claim the thermostat... Seems like a bad idea.
The only thing I don't like is embedding my user credentials in my app for a commercial application. If they get a hold of them they can do a lot of damage.. Too much power.. Too much risk..
Maybe this can be achieved using the local cloud, which I don't mind.. However my node is too bad in order to modify the code to handle this scenario..
What @kennethlimpc means with ‘AP’ is ‘access point’. There is the option of connecting to your Photon directly, without a middleman (router). But I guess that’s not what you’re looking for.
Do you absolutely want your project to not require credentials for the clients? You could make something where the clients create an account on your server, and you assign them a new accesstoken. That way you have a lot more control over the accounts.
If you’re willing to wait for a bit, the guys at Spark are working on solutions for scenarios like this. I’m not sure if they can share much about that, but it never hurts to ask @dave
Thank you Moors. I am actually not in a rush... I'l ask @dave to see if he has something under the sleeve. Il rather wait than develop something now. Since I am in no rush
@Moors7 Your work around sounds great though!
It's not that I don't want credentials in the client. I don't really mind to much.. But my obsessive compulsive inside keeps banging me saying that it's not a good idea to include hard coded credentials
I have a few moments to work backwards through my email, so here goes Here are some quick notes, apologies if I missed something, all of this will be well documented in the coming months.
Sharing access to a device for an app!
OAuth 2.0 is now supported on the api. We’re still building a nice GUI to manage your oauth client, but with this you can do the typical “This app is requesting permission to use your core, click yes for yes” popup window you see with other services online. This also typically will give you a short access token, and a longer-lived refresh token you can use to keep your session alive for longer periods.
Claiming a device / setting up wifi / controlling a device / product from an app
The photon, since it supports soft-ap, will be easier to setup from a mobile app. During the setup process, you can connect to the access point provided by the photon, and from there your app can give it credentials to your network, but you can also exchange a ‘claim code’ to the device. This ensures your smart appliance can always be controlled from your mobile app, and never gets into a state where it’s online but someone hasn’t claimed it yet.
@dave you are the man! Thanks for all the answers… From my point of view, I think the approach I need will be in the photon. When a client buys my device, I want him to only need the device “serial number” to claim it…
I still don’t grasp how I’m going to do that, but I guess that a combination of all things said here, will be the solution.
Questions:
will I be able to customize the webpage my clients will see when they configure the photon?
will I be able to setup the photon AP for wifi via Json or rest api? So that my client will connect his iPhone to the soft ap and then run my app and my app confit the photon using rest API messages?
1.) We’re building a really nice mobile SDK that gives you a framework for building a great app that lets your users easily claim the device, setup wifi, etc, etc. It’s totally customizable, but it also should have good defaults. If you’re hitting the wifi config page on the photon itself… I would assume that can be customized, but I haven’t experimented with that yet, I know you can build any kind of mobile app though, and that’s 100% customizable.
2.) I think the mobile SDK makes it easy to configure the photon. I grepped through the soft-ap / hal firmware quickly, and it looks like the HTTP page for the setup is copied from memory somewhere, so I’m thinking it can be modified in firmware, but @mdma is the authority on that.
Here are some quick notes, apologies if I missed something, all of this will be well documented in the coming months.