Under “Settings” within the Spark Build there is a blue button that reads “Reset Token”. Upon clicking that button, I am shown a new access token, and that access token works. The problem, however, is that my old access token continues to work. I am not sure why I’d ever want to request a new access token without invalidating my old one (for example, maybe it got leaked), and the expected behavior of “reset” in my mind is revoke old and grant new.
Here’s the strange part: if I reset my access token a 2nd time, the new token works but still isn’t listed via the API; the oldest token (the one listed via the API) continues to work, but the access token I had generated with the previous reset stops functioning.
Wow, this sounds like a high priority issue. I’d love to confirm this behavior but I have work to do today and would prefer not to mess up my cores / apps.
We are aware of this issue. Originally, getting a new access token did invalidate old tokens; however problems arose when you had multiple services requesting access tokens (like the IDE vs. the mobile app), because they would invalidate each other. This caused stuff to break unexpectedly.
We put in place a temporary fix to allow old access tokens to continue working unless they are actively invalidated through the API.
The long-term solution is a complete OAuth implementation, but that hasn’t bubbled up to the top of the priority list. In the meantime i think there is a consistency issue with regards to how the access token is generated in the IDE (which is different than through the API), and I think we can fix that in the near future.
Ok, good to know thanks. Sounds like all valid tokens are not being listed via the API though, so it might be hard to explicitly delete them if you have not written them all down as you were creating them.
This is pretty clear in the docs, maybe not that easy to find: “For now, Spark Build will list the single most recently created token.”
The token displayed in the settings panel is for the “user” client. Clicking the reset token button now deletes the most recent user client token and generates a new one. If you have multiple user client tokens, you will need to explicitly delete the older ones. We shouldn’t delete those since we can’t be confident we created them.
When the user client token shown in the web IDE expires, a new one will not automatically be created. The token will be highlighted in red, and you will see a notice of the expiration beneath it in the settings drawer.
The web IDE now uses a separate token for the “spark-ide” client to make its verify and flash requests. This token will be automatically regenerated without any user intervention so that the web IDE always works.
I am new with the platform and wonder why pressing the reset button in IDE settings, does not invalidate the previous token.
Confirmed in a browser afterwards also the day after with:
https://api.particle.io/v1/devices?access_token=[user token before reset in IDE]
In the CLI running $ particle token list the new user token after the reset in IDE is in the list, but the previous user token before the reset in the IDE is not in the list, despite still working in the http devices call above.
Is the status today that the previous user token must be deleted with the API or CLI?
Where can the previous user token be found for that purpose (I luckily copied it myself before pressing the reset button)?
