I’m a bit clueless about creating Particle tokens for iOS apps I’ve created. Currently, I’m simply providing a means to scramble and unscramble what I believe is the “user” token and providing the scrambled version to customers who are trying to control Particle devices via my iOS app. I’m absolutely sure this is not the right way to do things and I’m pretty darn sure this is highly discouraged.
When I list tokens, I see: “user”, “spark-ide”, “cloud-compile”, “PASSWORD_ONLY”, “PASSWORD_ONLY__ (active)” and “ifttt-5545” tokens. There are lots of the PASSWORD_ONLY flavor and a few others I haven’t listed.
I’m a bit embarrassed that I need to ask this question, but I simply can’t find the documentation that shows me how to better use the tokens. By the way, at this time for development and test systems, users don’t log in. They merely enter the deviceID into a field and the scrambled (user) access_token.
I see that I can create a token and even set one to never expire. However, I don’t see how I might limit what they can do with that token. Any guidance would be greatly appreciated and I suspect I’m not the only user who’s clueless about this issue.
Have you read through the Cloud API in the reference documentation?
If that still doesn’t make sense - could you share a model of what your architecture is and what access to the Cloud API you are wanting to give to a user of your iOS app?
Personally I don’t expose deviceIDs to end users - and the web app used doesn’t allow them to know the deviceID, rather a serial number is provided (which is the given device name). Are these devices products or on a personal account.
@armor, yes, I read through the Cloud API documentation, but still have questions. I’m merely trying to provide users of the devices I’ve developed the ability to use the iOS (and Android) app I created as a means to “control” their provided Particle devices in the sense of calling functions in the application. Everything works fine, but I’d like to know if I create a token via the CLI and provide it to the user, does it have limited privileges or is my entire personal account exposed?
I’m still evaluating if the device I’ve created has merit or is simply something that’s “interesting”. If it has legs, then I could consider going through the much more challenging effort to create user accounts, etc.
They are not part of a product…just claimed to my personal account. I’m just hoping they can only call app functions in my device apps and can not do other things to my account. It’s exceedingly unlikely they have the tech savvy to do anything. I just want to limit my exposure.
yeah, that's what I would think as well.
If you are very worried about your other devices, you could open a particle account for that specific prototype.
Cheers
Understand now - I think Gustavo’s suggestion about creating a special Particle user account is a good one to limit the exposure of your own account. It took me a while to get the product token access stuff working and I now have a cheat sheet to remind myself when I need to do anything (new, change, revoke).
Developer account tokens grant access to all features available to the user, including the ability to access all API calls and log into the console and build and perform most account operations.
Customer account tokens on a product only allow access to a small set of APIs (such as function and variable APIs) for that customer’s devices, and do not allow access to management functions, console, or build.
Thanks, all. I now understand and it explains why the documentation appeared a bit thin…it’s the way it works. I was obviously hoping I could create a developer token with limited privileges and just couldn’t see how.
I’ve built numerous devices of different functionality (20?) to field test with users and I’ll have to re-think my approach to developer devices vs products. I’ll also have to learn more about how to implement users and products.
It looks scary at the beginning (granted, it is time consuming), but once you get the hang of it, I am pretty sure it will be so convenient for future prototypes.
For the Particle folks and FWIW, I think it might be valuable to developers to be able to create a token that has limited privileges. And by “limited”, I mean the ability to call Particle functions and read Particle variables. The token would not permit further actions with the account and therefore represents limited risk.
I haven’t given this a significant amount of thought, but feel for my case, which I doubt it terribly unique, it would be comforting to know I can give someone a token (or include it in an iOS or other application) that has limited capability.
Perhaps I should submit this under feature request?
That’s what customers are for. It typically does not make sense for customers to be able to see each other’s devices, so you want to restrict it to a user, their device(s), and limited API calls. And you probably want to group all of your customer devices together somehow, since they will all have similar if not identical firmware. That’s what products are for.
@rickkas7 , Thanks for the feedback. I’ve always been afraid of implementing products and customers when I’m still developing the device(s) and there are many flavors of devices. I’ve also had the impression there’s a lot of work involved and I’d be required to set up a service against which users would authenticate and that’s been perceived as too much of a hurdle at this time. I really do need to research this further and replace the “fear” with more “knowledge”. Thanks.
If I connect the dots in what you say above:
if you were using products you wouldn't need to set up an auth service. You could continue to do the same you are doing now, just from a product perspective, claiming all devices in your account but in the context of a product.
Yes, the HTTPS requests your app does will change a bit for hitting devices in a product.
So my parting words are: Go Tom Go!
