Thank you Priya,
We actually already use
requireAccess() in our Sync function, now what I did not think about, is checking the logs on the sync gateway. If see some warnings in there after deleting the user:
2021-06-01T12:04:18.849Z [WRN] c:[2963c7e1] Error reloading user "ccb6f7089874194936876aa04bf5a2e5ae": User not found during reload -- db.(*Database).checkForUserUpdates() at changes.go:336
2021-06-02T08:38:04.624Z [WRN] c: Error reloading user "cc0ebcd2fe274044c88b68f3dcc0433186": User not found during reload -- db.(*Database).checkForUserUpdates() at changes.go:336
Maybe this is the reason why the pushes are still going through? We are currently running SG 2.7.3, I did not find any changes related to this in the release notes, we’ll update during offhours and see if this changes anything.
The error returned from SG (when
requireAccess rejects the change), is this something CBL will detect so we can hook into this to verify access is still valid?
We would have some device specific info stored on the client device itself (like the documentID referring to this client device). Due to our internal process of removing access, this client device document would get removed from all channels (so we don’t bloat client devices with lingering data), causing the
AccessRemoved flag to be set on all client devices for this document. We hook into the pull events on the client devices, and we compare the documentID of the
AccessRemoved with the locally stored document.
The app already restarts the replicator on different occasions, our app also asks a new token each time the replicator is being restarted (or just started), if the client device was revoked before, it won’t get a new token and the client device handles the rest of the process needed to clear it’s local database.
The only problem we’re currently still facing, is notifying the client device is revoked during an active sync.