I am trying to delete a user. I have deleted the account (no posts, no likes, no interactions) a number of times now and their ‘login details’ no longer work … but… they can still get in through a bookmark.
I have logged them out on all devices before deleting them, but that bookmark overrides everything I do.
Suspending is temporary. Blocking only inhibits interaction, but doesn’t block access to the forum and deleting IP-address is insufficient cos as long as they don’t delete that bookmark, they can log in via any other network.
That doesn’t seem right. If there is no account associated to the cookie/bookmark, then I’m not sure how they are getting access. Are they utilizing an API Key? If so, delete/disable all API keys and re-issue them to the services/users you feel should have them.
Otherwise, there is very little a bookmark can provide. As any interaction would require a valid UserID to go along with the reply/topic creation, otherwise, it will fail for obvious reasons.
I delete, they log back in. and the account is entirely new every single time.
i work via memberful. the user has been deleted in their system, deleted in WP, deleted everywhere (including in Discourse). i have tried deactivating (requires email activation) but that too is bypassed.
I have asked memberful, but since the user is no longer in their system, it’s not about them anymore.
with the information i had, i assumed it was because of the bookmark. but just now i tried to log in with her login details, and they still work.
so i can log into her account even though it’s just been deleted (again). and it instantly shows up as an entirely New account.
but Memberful puts the ball with Discourse based on their assumption that Discourse doesn’t allow for the deletion of accounts at all, so according to them, the glitch is with Discourse.
now, for me even finding the right words to describe what’s happening is already taxing to the max, as is interpreting your answers, so there’s no way for me to know whether the glitch is with Discourse or Memberful.
logic would decree it’s with them. but they don’t seem to know how to resolve it.
any suggestions on either side (including ones that i could pass on to them) would be greatly appreciated.
For some reason, I think @sam made this decision early on, we make it super hard to delete users who have a lot of posts. There are some site settings you will need to change to allow deletion of users with more than X posts and users with posts older than X. Two of them!
Anonymization might suffice if the user has many posts. Then you don’t get a bunch of swiss cheese deletion holes in existing conversations…
this user has 0 posts. and anonymizing her and logging her out does NOT log her out of the browser she’s in.
i would suppose that if i log her out, the moment she refreshes her page (or even if she doesn’t), she’d get the “OOPS, that page no longer exists” - but she’s still there.
but since i now have access to that account, i logged her out myself, tried to log back in and the old email settings still applied. so she hasn’t been anonymized.
since it requires sign up via memberful, that would indicate the glitch really is with them.
any suggestions i can pass on would still be appreciated.
and Edit for clarification: every time she logs in, she gets a new account. so the old one is gone. there’s simply a new one.
that has me thinking that by logging in she continuously creates a new account, just a regular new sign-up… except… she doesn’t appear in my Memberful dashboard and i don’t get notified…
Definitely, as SSO will generate a new account upon sign in if the account does not exist. So it seems Memberful is permitting the user to use their existing credientials to authenticate and thus is creating a new account in your Discourse instance.
will pass this on to them, because that needs looking into.
at the very least, i should be notified.
but ideally, it shouldn’t be happening.
and this was a free account, the settings of which are TL_0, but the paid accounts come in at TL_1 and 2, so i obviously want to be sure that nothing of the kind can give them automatic access to closed-off areas.
If this keeps happening, take a look at the user’s id and external id. If you open their account in the admin panel, you can find their id as the number in the URL, and their external id at the bottom.
If the new accounts have a new id, but the same external id, it’s definitely an issue of the SSO provider, because that would prove that Discourse is creating new accounts (with new ids) for the same external account.
If the external id changes, too, then the user is probably creating new accounts with your SSO provider.
)