There seems to be an issue with the adminapi when deleting all of a users sessions, it does not delete the sessions. If you delete an individual session is it deleted, but deleting all sessions for a user does not work. Sync breaks for the user on mobile, but the session remains. This used to work perfectly in previous versions, it is only since moving to 3.1 and then 3.2 that I noticed this bug.
From my point of view, I want an administrator to be able to revoke access for users by deleting all sessions for the user.
I wonder if in your own code, deleting a user does not delete all sessions because it relies on the same underlying mechanism as the sync gateway to delete all user sessions?
This is working as expected for me. Can you elaborate on how it’s not working?
You say sync breaks - do you mean the clients fully disconnect? Do they reconnect again using the same session?
Note, sessions do remain visible in the bucket for a period of time - but they are not in a usable state. We invalidate user sessions in a slightly different way vs. deleting them individually, which results in them remaining in the bucket for the duration of the expiry, despite not being usable by the user.
This is the error I get when attempting to use a session that was created before I issued an admin DELETE /db/{user}/_sessions request.
It is an administration task on our backend … when we archive a user we use the method to delete all sessions for that user … on the mobile device that is connected using the session sync stops working, I’m not sure when it changed but the sessions used to get deleted and it was easy to determine that the user was no longer had access and the app could be closed. But now, as far as I can tell the session still exists, the sync has stopped, but there is no way of detemining why sync has stopped, so the mobile app stays open with broken sync.
Within the rest api it is not possible to get a list of all open sessions for a user and delete then one by one, the only option would be to manually store session ids for each user, which is not something that makes sense given the sync gate has all this information. So we use the delete all method which no longer deletes the sessions, simple breaks the sync? Or is there a way to determine that the session has been invalidated and is awaiting deletion?
The specific behaviour around session invalidation on the SG side has not changed - what may have changed is how that interacts with the actively running replications.
The user will not be able to reauthenticate with their old sessions when they get disconnected from Sync Gateway. This is why I am curious exactly what you’re observing on the client side.
Perhaps some client-side logs and some input from the CBL team could be of use here.
Thats an interesting though, I can try to reauthenticate as the test to see if the session is now invalite rather than simply a replication issue … which would allow me on the mobile to close the app knowing that the session is no longer valid.
| 