You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Summary: RPC is not removing the device from MPS correctly during deactivation flow in Multitenant environments.
Scenario 1:
activate a device on tenant1, everything ok.
deactivate it without tenant (our bug); the device is deactivated but still present in MPS (expected).
activate it again with tenant1
deactivate it with tenant1; the device still remains in MPS !
Scenario 2:
activate a device on tenant1, everything ok.
deactivate it with tenant1; the device still remains in MPS !
activate the same device (guid) on tenant2; the device is activated but in MPS its record guid/tenant is missing, only the record with tenant1
So it seems that deactivating with the RPC does not remove the device from MPS. This is weird because deactivating should be the opposite of activating (which activates the AMT stuff and register the device in MPS).
More, if a device (guid) already exists in MPS for a tenant, the activation does not register it for other tenant. This scenario is an edge case, it is not expected that the same device to be activated for more tenants, but it may occur (for us, because we used the same device for more testing environments tide to the same MPS).
So two pb for RPC, one, activating does not register the device in MPS if the guid is already there, and 2, deactivating using the tenant flag does not remove the device from MPS.
We've found a workaround for this, after deactivation we use the MPS api to force complete device deletion (including secrets), and it seems to work. But this is just a hack, I believe that the RPC should add the guid/tenant device in MPS at activation and on deactivation delete it from MPS, together with the secrets of course (like the deactivate MPS api does).
Versions:
RPC-Go: 2.6.0
MPS: 2.11
RPS: 2.15
The text was updated successfully, but these errors were encountered:
Summary: RPC is not removing the device from MPS correctly during deactivation flow in Multitenant environments.
Scenario 1:
activate a device on tenant1, everything ok.
deactivate it without tenant (our bug); the device is deactivated but still present in MPS (expected).
activate it again with tenant1
deactivate it with tenant1; the device still remains in MPS !
Scenario 2:
activate a device on tenant1, everything ok.
deactivate it with tenant1; the device still remains in MPS !
activate the same device (guid) on tenant2; the device is activated but in MPS its record guid/tenant is missing, only the record with tenant1
So it seems that deactivating with the RPC does not remove the device from MPS. This is weird because deactivating should be the opposite of activating (which activates the AMT stuff and register the device in MPS).
More, if a device (guid) already exists in MPS for a tenant, the activation does not register it for other tenant. This scenario is an edge case, it is not expected that the same device to be activated for more tenants, but it may occur (for us, because we used the same device for more testing environments tide to the same MPS).
So two pb for RPC, one, activating does not register the device in MPS if the guid is already there, and 2, deactivating using the tenant flag does not remove the device from MPS.
We've found a workaround for this, after deactivation we use the MPS api to force complete device deletion (including secrets), and it seems to work. But this is just a hack, I believe that the RPC should add the guid/tenant device in MPS at activation and on deactivation delete it from MPS, together with the secrets of course (like the deactivate MPS api does).
Versions:
RPC-Go: 2.6.0
MPS: 2.11
RPS: 2.15
The text was updated successfully, but these errors were encountered: