I have a lot of questions on this

First.. What is being accomplished by this PR? Why is it here? This doesn't seem to solve a general problem that needs to be documented on the docs site. Seems more like an attempt to help solve something for a specific customer with a weird workflow, and not something we should document in general. And even so, I don't think it accomplishes what this change says it's doing. So i'm really confused here

So I believe the basic question being addressed here is, "what can I do if I want the device I'm sitting at to be immediately deauthorized from one or more ZeroTier networks?"

In the normal case, we can't do that due to the design of the ZT1 protocol. The fact that network membership is eventually consistent is a win for resilience and scale, but does cause confusion at best, and real user issues at worst, where the timeout on the existing membership/network config is too long.

It's an edge case, and deleting the local node identity is something we shouldn't point people to by default as it's an inherently unsafe action. (Once lost, that ID ain't coming back.)

OTOH, people go through all kinds of contortions and random troubleshooting steps trying to figure out why de-auths aren't immediate, and have even gone so far as to claim that ZeroTier is inherently "insecure" because we can't do atomic, immediate eviction of network members. Noting a workaround that allows people with the need or desire to see membership change right now seems worthwhile to me.

I do think we can specifically note that the identity deletion is an extra step only needed in specific cases. The current text could be read as saying, "you should do this to be safe," whereas the message we want to covey is more like, "if normal de-auth isn't fast or complete enough for you, you can take this somewhat more severe action...but here be dragons." (etc.)

@rcoder Yes, deleting an identity & restarting zerotier is probably the only way to go for completely removing a node from authorization immediately. The code in the example in this PR deletes authtoken.secret which is the API key used by zerotier-cli and the desktop UI to communicate with the background service. It doesn't have anything at all to do with SSO sesions or billing or the identity or anything else. So I'm not even sure what solution this documentation is trying to solve in the first place because it doesn't make any sense to begin with.

I had the wrong secret. Now with identity.secret

Thank you for the feedback Grant.

Thanks for making this. I think updating the docs instead of sending bespoke comments to every support case is something we need to do a lot more.

But this particular case is too highly specific to one specific user doing an unsupported thing *. I don't want people coming across this and trying to do it. People blindly copy and paste things and deleting the identity is unrecoverable.

It's not a matter of fixing a couple things in the PR but the idea itself. Sorry to say.

At least we learned a lot about the internals of the client in the process.

hope that helps

* user is trying to share 1 computer / node with multiple people. The node is using SSO to auth with a zerotier network. They want each person using the computer to have to re-auth with zerotier. This customer is on a canceled essential trial.

If de-authorizing a non-sso member doesn't work correctly, we should fix that.
If there is something confusing about sso (de)authorization, we should note that somewhere appropriate and improve the central design for it.