Delete member via controller API *doesn't*

[gdamore]

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.

[gdamore]

@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.

[laduke]

Does the same thing on my Mac.

[laduke]

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.

[gdamore]

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.

[adamierymenko]

Taking a look. Should get fixed in next release.

[gdamore]

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

[ertankucukoglu]

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

[Rich5]

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

[imxari]

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

[adamierymenko]

Fixed in dev

[jgentes]

@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]

Bump - could this be merged into the public release?

[laduke]

pretty sure this just shipped

[imxari]

Wasn't noted in the release notes.

[alpharde]

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

[laduke]

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

[imxari]

This will get fixed one day :P

[sinamics]

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

[taniaengel]

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!

[taniaengel]

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.

[jerrychong25]

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.

Related:

• Can't assign deleted IP address #258
• Unable To Remove Assigned IP After Deauthorize and Delete A Member Via Zerotier One localhost:9993 API dec0dOS/zero-ui#109
• Unable To Remove Assigned IP After Deauthorize and Delete A Member Via Zerotier One localhost:9993 API #1743

Thanks.