Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cannot create another user with the same username of a deleted user #1143

Open
anesuc opened this issue Mar 14, 2021 · 12 comments
Open

Cannot create another user with the same username of a deleted user #1143

anesuc opened this issue Mar 14, 2021 · 12 comments
Labels
confirmed bug Something isn't working features - miscellaneous Generic feature request up-for-grabs Not assigned yet
Milestone

Comments

@anesuc
Copy link

anesuc commented Mar 14, 2021

Hi all,

I just found a bug where if I remove a user from Admin (might do the same any other way, haven't tested), and I go to create a new user with the same username, it will fail saying to check error logs (checked both userFrost and php logs and there was nothing). This happened using the same username but a different email as well (so it's linked to the username). I've currently broken my myphpadmin to be able to check whats going on in the DB but I might make an effort later if this is a harder issue to debug.

User frost version: 4.4.5
PHP version 7.4.3

Edit: It turns out the email being the same also fails. So a past user can't join again.

Thanks,
Anesu

@lcharette
Copy link
Member

That's because the deleted user is "soft deleted", so it still exist in the db, which is the intended purposed. However, I agree, the ability to permanently delete a user from the UI would be useful, plus a better error message.

@lcharette lcharette added confirmed bug Something isn't working features - miscellaneous Generic feature request up-for-grabs Not assigned yet labels Mar 14, 2021
@anesuc
Copy link
Author

anesuc commented Mar 14, 2021

Alright. Yeah that would be useful! So deleting users directly in the users table will not break anything right?
Edit: Nvm it looks like there is other tables linked to the users.

@Delaney
Copy link

Delaney commented Oct 2, 2023

Hey @lcharette is this issue still open?

@lcharette
Copy link
Member

User are still soft deleted. Open to suggestion how to handle this in the UI / CLI / whatever.

@anesuc
Copy link
Author

anesuc commented Oct 3, 2023

I think there should be an option for an Admin in the Admin Dashboard to be able to permanently delete a user record. The option can be something specific along with a warning message etc thats fine.

@Delaney
Copy link

Delaney commented Oct 3, 2023

If emails or usernames from deleted accounts can be used again, my idea was to modify those fields and concatenate the deleted_at timestamp as a string to them, probably with a separator. Permanent deletion could break stuff.

@lcharette
Copy link
Member

A hard delete would mean all activities and other related data would also need to be deleted. Otherwise you'll get record without an associated user. In some cases it could break things. For example: "Project was created by {name} on {date}"... Delete the username, the project still exist, but not the Name (unless you hardcode the Name string, but that can bring other issue, if the name can change ;) )

@Delaney solution is another solution, but what if User1 gets deleted, User2 is created with the same email/username, and then you need to re-enable User1?

There's no "perfect" solution, and I think it comes back to each app how they want to handle it. But I agree it should be more obvious when a username is denied because of a deleted user.

@Delaney
Copy link

Delaney commented Oct 3, 2023

@lcharette So a different error message for cases where the username/email is unavailable because of a deleted user?

@StrykeSlammerII
Copy link

I've posted a sprinkle for UF4 which redacts basic user info (name and email) before doing the usual soft delete, and gives users a button for self-deletion.

I found it ran into one of the issues lcharette noted: base UF often hardcodes usernames in logs, rather referencing them. After a username is redacted, earlier logs keep the original username--and if someone later reuses an old username, it will look like the older logs are refering to the new user.

...but as a sprinkle, it gives a starting point if anyone wants to try out the concept.
It may need expanded to fit any app it actually gets used in, because it only redacts username and email address; it doesn't know anything about a new app it gets dropped into. Read the notes before using 😁

I intend to update it to UF5 once I get that running on my end, but I've been slacking off on that 😦

@lcharette
Copy link
Member

@lcharette So a different error message for cases where the username/email is unavailable because of a deleted user?

Not really, because you don't want to expose that a username exist, but has been deleted.

@H1ghSyst3m
Copy link

H1ghSyst3m commented Nov 4, 2023

Wouldn't a Dummy User a better alternative, so when I delete a User then, the data like username, e-mail, name, surname change to anonym, deleted_user or something like that. That would also be better for the Privacy.

The dummy Users can also have a unique id behind their name like "deleted_user_2853" or "anonym_2425"
and a blacklist for username and e-mail domain would be really good, so that no one registers itself with a username or e-mail like that.

Then also the activities will just show the dummy user

@lcharette lcharette added this to the 5.1.0 milestone Nov 25, 2023
@lcharette lcharette moved this to Todo 5.1.0 in UserFrosting Task Planner Nov 26, 2023
@StrykeSlammerII
Copy link

I've posted a sprinkle for UF4 which redacts basic user info (name and email) before doing the usual soft delete, and gives users a button for self-deletion.
...
I intend to update it to UF5 once I get that running on my end, but I've been slacking off on that 😦

UF5 community sprinkle has been published.
Undoubtedly still needs love, but it's a little more than core UF offers.

@lcharette lcharette moved this from Todo 5.1.0 to Todo 5.2.0 in UserFrosting Task Planner Mar 10, 2024
@lcharette lcharette moved this from Todo 5.2.0 to Not Started in UserFrosting Task Planner Apr 13, 2024
@lcharette lcharette modified the milestones: 5.1.0, 5.3.0 Apr 14, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
confirmed bug Something isn't working features - miscellaneous Generic feature request up-for-grabs Not assigned yet
Projects
Status: Not Started
Development

No branches or pull requests

5 participants