Yes, auth is controlled by Firebase Auth, and user details saved in Firestore also.
Currently our product is entirely Boron based, but very good info to have incase we start looking at wifi solutions.
@jgskarda apart from the fact that you want to keep device flexibility, are there any security concerns allowing a customer to know the Device ID of a system.
A part of me wants to just use the Device ID, but another part also want's to abstract the device ID to a custom serial number. With our other device, that is currently out with customers, we have had a scenario where a device went offline, and rather than troubleshoot onsite, we simply replaced the boron in the device. From a data continuity perspective, I think this scenario is easier to manage with the extra custom serial number abstraction.
I am not smart enough to know if/how big of a security risk this is. :). I've simply been figuring most of this stuff out as I go. That's what I love best about this community! I just figured it can't hurt keeping it in in my backend and making it difficult for a customer to know what the particle Device ID is. Although granted, the device IDs are still exposed to the HTML/browser and any savvy person could go look at what API calls their browser are making to Particle. But then again it's their device ID they already own so can't imagine that matters too much. I also wanted something a little shorter for someone to type in than the full Particle Device ID. I use a QR code scanner with the web app today for a user to claim a device from a mobile device, however, if that doesn't work for someone and they use a PC asking them to type in a full Particle Device ID and get it right the first time can be a bear. So I just shortened it up to 10 randomly generated characters to make up my Serial Number. Not sure if that's the best approach but it works for now. As I learn more maybe I'll change parts of it.
I do like your idea of data continuity by having your own serial number as well, although I'm sure it could be done via a stored procedure of some kind to transform the historical data. It just seems way easier to assign the new serial number to the same as the old one. I currently store data using the particle's device ID as the identifier on where it came from... looks like I should switch that to use the serial number for this reason. I.e. What I should do is: device reports data to the cloud, I look up what the serial number of that device is, and then store that sensor data to a table based on Serial Number and not device_id. More things to add to the list of ToDos.
I think I am learning the hard way of another big caveat to the claiming process when claiming each device to each customer within Particle vs just claiming them all to a generic admin type account. The device MUST be connected to the cloud for the claiming process to work correctly. If the device is not currently connected the response you receive is "errors": ["Device is not connected to the cloud"]. After sending several units out to customers, many people just take the product out of the box, try claiming it before ever turning the device on and waiting for it to connect. In this scenario they are unable to claim the device within Particle cloud. Rather, they first must turn on the device, wait until it connects and THEN claim the device. Just adds to some possible confusion to that process.
Given this, I think I'll be switching to a single "admin" type account that all devices are claimed under. This way within my own backend the device can still be claimed when offline.
@rickkas7 - What's the rationale to requiring the device to be online for claiming to a customer within Particle? Is there any work around for this or alternative or is the best thing to do like you said earlier and create a single admin account. Is this called out in the Docs anywhere? I tried looking but didn't see anything specific to requiring it to be online.
I think for wifi products the claim process happens when the customer sets the wifi credentials, so the device gets connected to the cloud.
I think cellular devices do not need to be online in order for them to be claimed.
@gusgonnet I believe this is incorrect and in fact, the device must be connected to Particle for the claiming process to work. That is at least when using the cloud API and for a product. This was asked in this chat: Offline Claiming - #2 by rickkas7 where @rickkas7 gave a similar answer. I also tested this several times and IF the device is offline, then the cloud API response is: “{"ok": false, "errors”: [“Device is not connected to the cloud”]}. If the device is online, then it's successful. For now, I just flash a message back to the user to indicate they must power on the device first before trying to claim it. This will work for now but pretty sure I'll migrate to a single admin account within Particle that all devices are claimed to.
One thing of special note, is just because the device was recently powered off, doesn't mean it's "offline" yet, there must be some sort of timeout period before the particle cloud indicates offline (maybe the 23 minute keep alive?). For example, devices still show connected for a period of time after powering them off. This was the confusing part for me in my initial testing as I didn't wait long enough for the particle cloud to indicate it was truly offline like the last device ID in this picture of a gray dot vs the breathing cyan within the console.
Not really sure why this is a limitation. I don't think the device itself knows who it's claimed to so why does it have to be connected for this? Maybe it does. Maybe this is by design and if by design, I'd be interested in hearing what the rationale is/was when implemented. All more of a reason I think to have a single admin account claim all devices for cellular products (i.e. able to subscribe to events since it is claimed, and able to do offline claiming since that is only linked in our own backend)
It used to be true that claiming a device could only occur if the device is online, and it’s still true for customer claiming.
However, in the case where you have devices claimed to the product owner (more common for cellular devices), the device no longer needs to be online. The steps are:
Add the device ID to your product
Claim the device from the product owner’s account. This even works from the Particle CLI using particle device add or you can use the cloud API directly.
@rickkas7 - Yes, agreed. The device can be claimed to a product owner account when offline, however, it can not go from part of a product with a status of “unclaimed” and then be claimed to a customer account unless online correct? I currently, create a customer account within the particle cloud and then that customer claims the device. I’m now re-thinking that decision but not being able to claim to a customer account when offline is the behavior I am seeing.
@rickkas7 - What’s the rationale for this limitation? Is this a hard technical limitation or is this a software/purposeful limitation implemented by Particle?. Only scenario I could think of is this prevents someone from claiming devices they don’t own (i.e. probably still sitting on shelf or in a box if not powered/connected) but otherwise, why would this limitation exist for customer accounts?
