Delete member via controller API doesn't

Question

Delete member via controller API doesn't

gdamore opened this issue 6 years ago · comments

Deleting a network member using the controller API does not actually delete the resource.

Instead, it looks like it just does the equivalent of a GET.

I would have expected the member to be removed, and the result code to be an HTTP 204 (No Content) result with no JSON body.

Note that this is on a macOS host with the most recent code. API version 4. The member was originally created using a POST to the API.

Best example is curl trace:

garrett@garretts-mbp{11}% curl -v -X DELETE -H 'X-ZT1-Auth: 62865eee65d89bd17465264a' http://localhost:9993/controller/network/2d2f619ccc8d59ee/member/0123456789
*   Trying ::1...
* TCP_NODELAY set
* Connected to localhost (::1) port 9993 (#0)
> DELETE /controller/network/2d2f619ccc8d59ee/member/0123456789 HTTP/1.1
> Host: localhost:9993
> User-Agent: curl/7.54.0
> Accept: */*
> X-ZT1-Auth: 62865eee65d89bd17465264a
>
< HTTP/1.1 200 OK
< Cache-Control: no-cache
< Pragma: no-cache
< Content-Type: application/json
< Content-Length: 540
< Connection: close
<
{
 "activeBridge": false,
 "address": "0123456789",
 "authorized": false,
 "capabilities": [],
 "creationTime": 1537894419768,
 "id": "0123456789",
 "ipAssignments": [],
 "lastAuthorizedCredential": null,
 "lastAuthorizedCredentialType": "api",
 "lastAuthorizedTime": 1537894459717,
 "lastDeauthorizedTime": 1537894473719,
 "noAutoAssignIps": false,
 "nwid": "2d2f619ccc8d59ee",
 "objtype": "member",
 "remoteTraceLevel": 0,
 "remoteTraceTarget": null,
 "revision": 3,
 "tags": [],
 "vMajor": -1,
 "vMinor": -1,
 "vProto": -1,
 "vRev": -1
* Closing connection 0
}

Then if you look again, it's still there:

garrett@garretts-mbp{12}% curl -v -H 'X-ZT1-Auth: 62865eee65d89bd17465264a' http://localhost:9993/controller/network/2d2f619ccc8d59ee/member
*   Trying ::1...
* TCP_NODELAY set
* Connected to localhost (::1) port 9993 (#0)
> GET /controller/network/2d2f619ccc8d59ee/member HTTP/1.1
> Host: localhost:9993
> User-Agent: curl/7.54.0
> Accept: */*
> X-ZT1-Auth: 62865eee65d89bd17465264a
>
< HTTP/1.1 200 OK
< Cache-Control: no-cache
< Pragma: no-cache
< Content-Type: application/json
< Content-Length: 46
< Connection: close
<
* Closing connection 0
{"2d2f619ccc":1,"0123456789":3,"964474c234":1}

I have not tested this via the "Central API" yet, but that's next.

Garrett D'Amore · Answer 1 · Wed Sep 26 2018 01:02:18 GMT+0800 (China Standard Time)

@janjaapbos Member deletion was one of the things I was adding to the proxy. But it doesn't seem to work unless this is fixed.

Travis LaDuke · Answer 2 · Wed Sep 26 2018 01:47:47 GMT+0800 (China Standard Time)

Does the same thing on my Mac.

Travis LaDuke · Answer 3 · Wed Sep 26 2018 01:54:44 GMT+0800 (China Standard Time)

Setting authorized to false and clearing ipAssignments, capabilities, and tags would be a workaround.

Since the node will keep trying to join, this is pretty much what a DELETE would accomplish.

Garrett D'Amore · Answer 4 · Wed Sep 26 2018 01:57:29 GMT+0800 (China Standard Time)

This isn't the same thing if the node was added manually, or has been destroyed. (Meaning that the node is not trying to join.)

The DELETE method gives a chance to clean up stale nodes. When you consider the case of ephemeral nodes (which NNG can and does create), the ability to delete becomes even more important.

At any rate, the API documents clearly state that DELETE should work.

Adam Ierymenko · Answer 5 · Wed Sep 26 2018 01:59:41 GMT+0800 (China Standard Time)

Taking a look. Should get fixed in next release.

Garrett D'Amore · Answer 6 · Wed Sep 26 2018 02:17:31 GMT+0800 (China Standard Time)

So Central seems to lack any API support for this either. It would be nice to have it; treat it as house cleaning.

ertankucukoglu · Answer 7 · Mon Feb 25 2019 18:29:38 GMT+0800 (China Standard Time)

I have same behavior on Raspberry Pi using ZeroTier version 1.2.12.
Using DELETE on IP does not actually delete a member.

Rich5 · Answer 8 · Tue May 14 2019 23:15:54 GMT+0800 (China Standard Time)

I can confirm similar behavior on v1.2.12 running on Ubuntu 18.04

imxari · Answer 9 · Mon Jun 10 2019 18:34:39 GMT+0800 (China Standard Time)

Bump - can confirm that this is an ongoing issue with version 1.2.12

Adam Ierymenko · Answer 10 · Wed Jun 12 2019 02:00:06 GMT+0800 (China Standard Time)

Fixed in dev

James Gentes · Answer 11 · Fri Jun 28 2019 01:21:41 GMT+0800 (China Standard Time)

@adamierymenko It looks like the last release (on the releases tab, not sure if this is accurate) was a year ago. Is there a way to deploy the dev branch, or any ETA on when this will be merged into the public release?

imxari · Answer 12 · Fri Aug 02 2019 02:31:41 GMT+0800 (China Standard Time)

Bump - could this be merged into the public release?

Travis LaDuke · Answer 13 · Fri Aug 02 2019 03:14:06 GMT+0800 (China Standard Time)

pretty sure this just shipped

imxari · Answer 14 · Tue Aug 06 2019 21:56:49 GMT+0800 (China Standard Time)

Wasn't noted in the release notes.

Glauber Ferreira · Answer 15 · Thu Sep 12 2019 06:13:44 GMT+0800 (China Standard Time)

Umm, in which version? I'm using the latest on repos (1.4.6) and I still get this.

Travis LaDuke · Answer 16 · Thu Sep 12 2019 06:35:05 GMT+0800 (China Standard Time)

Looks like it deletes it from the file, but not from memory 😅

imxari · Answer 17 · Thu Sep 12 2019 16:53:18 GMT+0800 (China Standard Time)

This will get fixed one day :P

Bernt Christian Egeland · Answer 18 · Tue Jan 05 2021 23:39:15 GMT+0800 (China Standard Time)

any update on this issue? Still not working on v1.6.2

Tania S Engel · Answer 19 · Tue Apr 06 2021 05:26:09 GMT+0800 (China Standard Time)

I have found that this does not work on Windows platform using ZeroTier 1.6.2 in a private network. 1st I remove the member identity as a root from the VL1 configuration. Then I tried all this separate options for VL2 removal:

DELETE http://localhost:XXX//api/network/$networkId/member/$memberId - as said above, just works like GET but does delete the member.json from C:\ProgramData\ZeroTier\One\controller.d\network$networkId\member. Regardless, the member is still able to communicate and the json will reappear.
POST http://localhost:XXX//api/network/$networkId/member/$memberId setting authorized=false and clearing the lastAuthorizedCredentialType, lastAuthorizedCredential, lastAuthorizedTime, ipAssignments, capabilities ... does indeed update the member, but the unauthorized member can still communicate. It's network status is OK. I would expect it to be ACCESS_DENIED just as if it had never been authorized.
Stop ZT. Delete the C:\ProgramData\ZeroTier\One\controller.d\network$networkId\member$memberId.json. Start ZT

Now in this case, a subsequent GET actually returns an error as one would expect. The member does not exist. HOWEVER,
@laduke the memberId.json will appear in the network member directory ONLY when the remote member contacts the ZeroTier network controller. When you say it is in ZeroTier memory, where is the memory stored on windows?

The only way to work around this is have the member leave the network, which obviously is what we are all trying to get around. Or to create a new network controller and have all the members you want to keep join. It seems the network controller should have more control!

Tania S Engel · Answer 20 · Fri May 21 2021 00:26:46 GMT+0800 (China Standard Time)

After discussing this with ZeroTier, the best course of action is to only
POST http://localhost:XXX//api/network/$networkId/member/$memberId setting authorized=false
when you want to block a member from your network. Do not restart ZeroTier. The member should get access_denied and should no longer be able to communicate.

The DELETE could be used later when a member has been de-authorized for a long period of time. There is no need to restart the service after VL2 changes using the API.

Jerry Chong · Answer 21 · Sat Aug 27 2022 14:45:37 GMT+0800 (China Standard Time)

I have found that this does not work on Windows platform using ZeroTier 1.6.2 in a private network. 1st I remove the member identity as a root from the VL1 configuration. Then I tried all this separate options for VL2 removal:
1. DELETE http://localhost:XXX//api/network/$networkId/member/$memberId - as said above, just works like GET but does delete the member.json from C:\ProgramData\ZeroTier\One\controller.d\network$networkId\member. Regardless, the member is still able to communicate and the json will reappear.

2. POST http://localhost:XXX//api/network/$networkId/member/$memberId setting authorized=false and clearing the lastAuthorizedCredentialType, lastAuthorizedCredential, lastAuthorizedTime, ipAssignments, capabilities ... does indeed update the member, but the unauthorized member can still communicate. It's network status is OK. I would expect it to be ACCESS_DENIED just as if it had never been authorized.

3. Stop ZT. Delete the C:\ProgramData\ZeroTier\One\controller.d\network$networkId\member$memberId.json. Start ZT
Now in this case, a subsequent GET actually returns an error as one would expect. The member does not exist. HOWEVER, @laduke the memberId.json will appear in the network member directory ONLY when the remote member contacts the ZeroTier network controller. When you say it is in ZeroTier memory, where is the memory stored on windows?

The only way to work around this is have the member leave the network, which obviously is what we are all trying to get around. Or to create a new network controller and have all the members you want to keep join. It seems the network controller should have more control!

Hi @taniaengel ,

Sorry for bumping out old thread here.

I would like to deauthorize and delete a member via Zerotier localhost:9993 API as mentioned in https://docs.zerotier.com/self-hosting/network-controllers/.

Unfortunately, the API unable to remove assgined IP (In this case 10.1.1.200).

DELETE Member API Details:

Request:
curl -X DELETE "http://localhost:9993/controller/network/XXXXXXXXXXXXXXXXX/member/aaaaaaaaa" -H "X-ZT1-AUTH: auth_token_here""

Response:
{}

GET Member API Details:

Request:
curl -X GET "http://localhost:9993/controller/network/XXXXXXXXXXXXXXXXX/member/aaaaaaaaa" -H "X-ZT1-AUTH: auth_token_here"

Response:
{
 "activeBridge": false,
 "address": "aaaaaaaaa",
 "authenticationExpiryTime": 0,
 "authorized": false,
 "capabilities": [],
 "creationTime": 1660278611038,
 "id": "563af8b3a5",
 "identity": "aaaaaaaaa:0:eacd8f65052054d842881f8bb530ea8e6750e262501783f2e8944ea16d4080684f25333dde47af796e27fac16bb8841494ecd164f5b0924b6beb1b0208699999",
 "ipAssignments": [
  "10.1.1.200"
 ],
 "lastAuthorizedCredential": null,
 "lastAuthorizedCredentialType": "api",
 "lastAuthorizedTime": 1660485003251,
 "lastDeauthorizedTime": 1661579147643,
 "noAutoAssignIps": false,
 "nwid": "XXXXXXXXXXXXXXXXX",
 "objtype": "member",
 "remoteTraceLevel": 0,
 "remoteTraceTarget": null,
 "revision": 8,
 "ssoExempt": false,
 "tags": [],
 "vMajor": 1,
 "vMinor": 10,
 "vProto": 12,
 "vRev": 1
}

After I've deleted a member, there is no way I could delete the assigned IP anymore.

Any solution to solve this issue via API only?

So that previously assigned IP could assign to new member ID.

Delete member via controller API *doesn't*

Delete member via controller API doesn't