If I am using two-legged authentication, and the Particle API is truly opaque to my customers why must I supply an email address when creating a new product scoped customer?
The Particle shadow customer should be created at the exact time that the customer is created in your system.
My thinking goes like this. I would like to create some sort of email validation system to ensure that my users are creating valid email accounts within my web application. If I create a customer before I validate their email there is a chance that the email will be wrong. The Particle API doesn't seem to let you view customers after they are created or delete customers, it seems their only value is to be a handle for creating tokens and claiming devices. This leads me to think, why can't I just create a unique identifier (e.g. "abcdefg12345") that I pass instead of an email address and store that as my particle_customer_id. Is there any real reason that this actually needs to be an email address? The documentation seems to all request a email address, is there any harm in just supplying a GUID instead?
Using this system I can truly create my customer before they have validated their email and I can manage their email address in my application without worrying about what the presentation of that is in Particles.
Our product requires us (US Law) to guarantee that third parties have certain controls over customer information. So, we are messing with taking the device ID and using that as the client email in the Particle ecosystem’s shadow customer email.
Seemed like a logical helper, though we are not sure what it may possibly do for us, at this time.
I believe that particle shadow emails cannot change once setup, so we are (to a lesser extent) worrying about “what if Harry gives/sells his device to Sally.” For us it means we need a (customer UI) method to un-claim a device on the customer end (or deal with the cost of a customer contact call). An issue, but not a show stopper yet.
Elightening.
One critical question about how to proceed with a product…
Our product, a pump controller, will be sold to a number of corporate customers. Each customerCo has employees in groups around the country that will manage overlapping subsets of the devices, and each device may be configured by overlapping groups of end-users. For example, devices may be purchased by CustomerCoA and placed at various sites owned by their clients ClientX and ClientY in Boston and Chicago. Adjustments to a given device may be required by employees of CustomerCoA or a client Co. Initial setup will be performed by an employee of CustomerCoA, and CustomerCoA will be the owner of the device.
User management and web app authentication will be in a database such as Firebase. I was planning on simply having any CustomerCoA user be able to provide or remove access to their authorized devices (database and optionally hardware) to any other user. The problem comes when deciding on how to give users access to the hardware, since that requires particle.io authentication.
My options:
Set up one master account on particle.io for CustomerCoA for potentially thousands of devices with hundreds of concurrent users in different areas. The web app/database user management will ensure that only data from devices authorized will show up. This likely means that the web app will have to store a permanent token for CustomerCoA and use it for calls to the particle api to get a session token, which is then used to display the particle functions/variables for a given device. It would mean that numerous end-users are accessing devices owned by this one particle account. Is there a limit to how many users can authenticate with the same account at one time, using the same token?
Set up a separate account for each device and create a fake customer in our web app database to claim it, then use that pseudocustomer for authenticating various end-users when they control a device. Is the method @BulldogLowell discussed (usingDEVICE_ID@ourProductID.com as the customer email for claiming the best way to go?
Resolving this question is a critical step in designing the web app.
If you are creating customers in your own space and using Particle Shadow customers…
You could create (in your own environment) the ability to create a link from the (let’s call him an) Admin’s account. You see, you need to have the device IDs of the Admin stored somewhere anyways and you have the Shadow Customer ID in the DB also.
This would then enable you to link and list shared devices by using a common DB table from which to retrieve Device ID’s and the Particle Shadow Customer ID.
Then, armed with the deviceID and the Shadow Customer ID, you can have any user authenticate and obtain an access token using OAuth token…
yes, that may work quite nicely. You could get a little spicier and enable any user to add a new device to the common list. You can create revenue by charging for extra user setup on a company account, even.