I’m dealing with an issue with my app, I’ve deleted a specific user while he was browsing through the app. Instead of being asked to sign-in again, he just returned to the first page where he had to enter his details (name…). On my sheet the line about this user disappeared before returning to the sheet after that it has been deleted.
That can be quite concerning if some sensitive data must be deleted immediately.
Deleting a user (while they’re signed in) does not sign them out. They remain signed in, but act as if it’s the first time they’re signing in.
By ‘user still able to access data’, what data do you mean?
To me that seems to be wrong procedure. They should be signed out to avoid any security breach.
Well, they returned back to the page where they had to enter their names & first names and the name appeared the first time but not the second. I’m not saying that seeing his name is a security breach but for other data that can be concerning because the deleted row returned back. (My sheet has row id…)
Is this a Private Pro app?
Nope, basic
I’ve testing and I’m pretty confident that removing a user from the whitelist sheet in a Private Pro app will sign them out immediately.
However, it’s hard to say what would happen with a Public with Email app because nothing would stop the user from simply signing into the app again, so there is no immediate need to sign them out. With that said, there is still internal data within glide that is still maintained (such as user specific data and I assume login authentication). Simply removing a row of data from a sheet wouldn’t sign the user out or remove the internal data for that user.
Instead, I would be curious what would happen if you delete the actual internal user data while a user is signed in. I’m not sure what would happen in that case, but I’m pretty confident that only removing a user profile row will not affect a user all that much, other than removing their data and any conditions based on that data.
You won’t be able to “delete” or block a user from a public app. To do this, you would need a whitelist function, like the Private Pro plan offers.
You could control visibility in public apps to some specific email addresses, but any other email can still log in and poke around at unprotected data.
I did some testing in a whitelist app a while ago and when I removed the user from the whitelist, it took a few minutes for them to be booted out. I can’t remember if it booted them during a session, or only after the closed and re-opened the app though. I would think it should happen at the next sheet sync with Google though.
The last time I tried it, it kicked the user out within a few seconds, but I suppose it depends on if you are removing the email from a google sheet or from within glide.
It didn’t kick the user out. I just wanted to see you guys were also dealing with that issue. I think that a correction is preferable for all tiers.
So out of curiosity, you are saying that you want a user to be signed out when removing a user profile record and/or internal user data. Would you would be fine with them just signing in again, or are you saying that you want to blacklist them?
Well it depends, the most preferable solution (and to me the most needed) is to have the user immediately logged off and having them signing again. About the blacklist, that must be a feature that has to be considered, if for example you have a « spammer » it’ll be fine to stop him/her logging in your app.
Got it. Yeah blacklisting would definitely be a useful feature for all tiers, but it’s still easy to use a fake address. Same with any public app though.
At most, you could probably put a condition on all of your tabs to only show if the user profile email is not empty. That should remove all tabs from view while still allowing for an onboarding process if you have one. With that the user would probably still have to sign out themselves, or you could show a separate tab that tells them to sign out. Don’t quote me, but I also believe if the user then attempts to sign in again, that will not regenerate the user profile row. I think to get the row to regenerate, you would also have to delete the internal user data.