🚀 Feature: Delete all user sessions on blocking a user

[prechILLEd]

🔖 Feature description

When deleting a user in the appwrite backend the sessions are still stored and not deleted.

Therefore a different user using the same device wont be able to sign in because the request is completely blocked.

🎤 Pitch

In my use-case it would make more sense to delete all sessions when a user is blocked since other users might not be able to sign in because the requests get rejected due to the blocked users sessions.

Steps:

1. Sign in with user A
2. Block user A in the appwrite backend
3. Restart App/Reload Website
4. Try to sign in with User B
5. Getting "AppwriteException: user_blocked, The current user has been blocked. You can unblock the user from the Appwrite console. (401)"

👀 Have you spent some time to check if this issue has been raised before?

• I checked and didn't find similar issue

🏢 Have you read the Code of Conduct?

• I have read the Code of Conduct

[JorensM]

I think an even better solution would be to automatically end the previous session if a new session is being created. I'm not sure about the security concerns of this though

[prechILLEd]

For that use-case it is probably best to set the session limit per user to 1 in the Auth Security tab.

You might want a user to be logged in on multiple devices at the same time and your thought would deny that.

[joeyouss]

Hi, thank you for opening this issue, but would it make sense for you to maybe set the limit once and then try it out? https://appwrite.io/docs/authentication-security#limits

I thinj, there are some potential downsides to doing this. In some cases, retaining the session might be necessary for auditing or investigative purposes, especially in applications that require high security. Also, automatically deleting sessions could result in data loss if the user was in the middle of an unsaved task. There might be scenarios where an account is temporarily blocked due to some system or admin error. In such cases, deleting all sessions would force the user to log back into all devices, which could be an inconvenience.

Can you let me know if setting the limit does the work for you and what are your thoughts?

[prechILLEd]

Thanks @joeyouss for the detailed answer.

You are totally right. You do not want to delete all of the users sessions for that purposes.
For my in-house app it does not really matter if data is lost.

Even with a session limit set to 1 my issue would still be not fixed - beside the fact it is not my goal to limit the user to have only 1 active session.

As a workaround I wrote a function that deletes all sessions for every user that is blocked.
It gets triggered when a user tries to sign in and get a "AppwriteException: user_blocked, The current user has been blocked. You can unblock the user from the Appwrite console. (401)" and tries to sign in again with the credentials given. This works fine for me!

I think it is not necessary to still work on this issue due to Joe's explanation.

[prechILLEd]

Just noticed I can not execute the function from that session since the "current user is blocked" and can not execute a function with "any" execute access.

Any workaround to recommend?

[prechILLEd]

Changed to a scheduled execution every 15 minutes which is totally fine for me.

For me this is kinda solved now with this workaround.

[sudormrfbin]

Changed to a scheduled execution every 15 minutes which is totally fine for me.

Another option would be to write a function that is triggered on the users.*.update.status event.

There is a small caveat tho, as mentioned in the Known Limitations section:

When events fire, only existing subscriptions for that event will receive the update. If your client or server side integrations lose network connection temporarily, delivery of the event is not guaranteed.

For self-hosted instances, when the Appwrite containers are shut down and restarted, events with pending webhooks and subscription updates will not be delivered.

[stnguyen90]

We would like to move forward with updating the Update user status API to also delete sessions.