Update examples.md with logout in Python #217
Conversation
Document the several steps in code which are required to both deauthorize and remove the secret required during a _logout_.
aaronjohnson
requested review from
laduke,
danitheturtle,
rcoder,
glimberg and
joseph-henry
as code owners
|
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 |
docs/api/central/examples.md
Outdated
| try: | ||
| if os.name == 'nt': | ||
| token_path = r'C:\ProgramData\ZeroTier\One\authtoken.secret' | ||
| else: | ||
| token_path = '/var/lib/zerotier-one/authtoken.secret' |
There was a problem hiding this comment.
Why are you removing authtoken.secret?
There was a problem hiding this comment.
In order to effect an immediate logout on a device used by more than one SSO login.
There was a problem hiding this comment.
deleting authtoken.secret doesn't do that. There's nothing you can do from the client side to do that.
|
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 |
identity.secret _not_ authtoken.secret
aaronjohnson
changed the title
|
I had the wrong secret. Now with identity.secret |
Add link to troubleshooting reset-node-id
remove tailing comma
|
Thank you for the feedback Grant. |
docs/api/central/examples.md
Outdated
| @@ -207,6 +210,101 @@ Invoke-WebRequest -Uri "https://api.zerotier.com/api/v1/network/$NWID/member/$ME | |||
| -Method Post -Headers $headers -Body $body -ContentType "application/json" | |||
| ``` | |||
|
|
|||
| In addition to notifying Central with this API call, and in order to not require waiting until the current credentials expire, the ZeroTierOne service needs to be stopped and the authtoken.secret needs to be removed. The API call in addition to the removal of the local secret file prevents incremental billing to increase unbounded in cases of repeat auth/deauth use cases. Also note, the deauthorize is required per individual network within an organization the node is present. | |||
There was a problem hiding this comment.
authtoken.secret has absolutely nothing to do with any of this. authtoken.secret is the API token to access the REST API of the local service.
docs/api/central/examples.md
Outdated
| In addition to notifying Central with this API call, and in order to not require waiting until the current credentials expire, the ZeroTierOne service needs to be stopped and the authtoken.secret needs to be removed. The API call in addition to the removal of the local secret file prevents incremental billing to increase unbounded in cases of repeat auth/deauth use cases. Also note, the deauthorize is required per individual network within an organization the node is present. | ||
|
|
There was a problem hiding this comment.
again, authtoken.secret plays no role in this at all.
docs/api/central/examples.md
Outdated
| try: | ||
| if os.name == 'nt': | ||
| token_path = r'C:\ProgramData\ZeroTier\One\authtoken.secret' | ||
| else: | ||
| token_path = '/var/lib/zerotier-one/authtoken.secret' |
There was a problem hiding this comment.
deleting authtoken.secret doesn't do that. There's nothing you can do from the client side to do that.
docs/api/central/examples.md
Outdated
| In addition to notifying Central with an API call, and in order to not require waiting until the current credentials expire, the ZeroTierOne service can to be stopped, authtoken.secret removed, and service restarted. For example, on a device which is shared and requires each user to provide separate SSO credentials to access the network. | ||
| This also prevents unbounded incremental billing in repeat auth/deauth use cases. | ||
|
|
||
| NB: the deauthorize is required per individual network within an organization the node is present. | ||
|
|
There was a problem hiding this comment.
This is still incorrect on a few of levels.
- It still references
authtoken.secret - Removing
authtoken.secretdoesn't reset SSO. Just the API key thatzerotier-cliand the Desktop UI use to communicate with the service - The node remains authorized until the lifetime of the access token used to authorize it expires.
- Assuming you mean
identity.secrethere, it will not prevent unbound incremental billing as it'll be a new node ID and charged anyway.
|
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. |
Document the several steps in code which are required to both deauthorize and remove the secret required during a logout.