Skip to content

[Bug]: The user who has not been approved should be automatically deleted from the system #4434

Closed

Description

@informapirata

Requirements

  • Is this a bug report? For questions or discussions use https://lemmy.ml/c/lemmy_support
  • Did you check to see if this issue already exists?
  • Is this only a single bug? Do not put multiple bugs in one issue.
  • Is this a backend issue? Use the lemmy-ui repo for UI / frontend issues.

Summary

Users who have requested registration, but who have not been approved by the administrators, are still present.
This appears to be a violation of the GPDR, as it does not allow users to delete their nickname (which in some cases could be a nickname containing a first and last name).
It may also constitute an anomaly in the instance's overall user count.

Steps to Reproduce

  1. (If you are an administrator) you can access the link https://[INSTANCE]/registration_applications and go back to the first page to locate the first rejected users
  2. Open the user page
  3. You will see that the user exists
  4. You can copy the user's page address (for example https://feddit.it/u/sprovdostauropode, a test user we created two years ago to test the function that rejects user approval)
  5. You can paste the user's address into a search box of any other federated software
  6. You can see that the user exists (for example here: https://mastodon.social/@sprovdostauropode@feddit.it)

The problem is perhaps less serious than that reported in issue LemmyNet/lemmy-ui#2384 but nevertheless should not be underestimated

Technical Details

There are no further technical details

Version

0.19.3

Lemmy Instance URL

It's not relevant

Activity

  1. dessalines commented on Feb 8, 2024

    @dessalines
    Member

    Not exactly sure how to go about solving this one. The only thing I can think of is adding a clean up job in our scheduled tasks to delete unapproved users older than X time, maybe a month.

  2. informapirata commented on Feb 8, 2024

    @informapirata
    Author

    I can think of is adding a clean up job in our scheduled tasks to delete unapproved users older than X time, maybe a month

    I am convinced that it would be appropriate to implement a function of this type within the system, because it would allow all administrators the possibility of cleaning: In fact, not all administrators are able to intervene on the database tables without causing damage.

    Clearly it is not yet completely in line with the "privacy by design" principle, but if it were not possible to create automatic deletion mechanisms, then periodic alerts could be created for administrators or this cleaning procedure could be integrated with each new update of the instance to Lemmy's latest release.

  3. Nothing4You commented on Feb 8, 2024

    @Nothing4You
    Collaborator

    FWIW, it should already be possible to have automatic cleanup by querying applications via API and issuing a purge via API, without resorting to DB editing.

  4. changed the title [-][Bug]: The user who has not been approved should be automatically deleted from the system (GDPR right to erasure violation)[/-] [+][Bug]: The user who has not been approved should be automatically deleted from the system[/+] on Feb 8, 2024
  5. Security-Chief-Odo commented on Feb 8, 2024

    @Security-Chief-Odo

    Not exactly sure how to go about solving this one. The only thing I can think of is adding a clean up job in our scheduled tasks to delete unapproved users older than X time, maybe a month.

    When the instance admin clicks deny on the user application. Yeet the user DB entry. Due to the way the relation is setup between the local_user and application tables though, that would delete the application as well. If you want to keep the denied application around even after the user is deleted, then you'll need to rework the application process. Don't create a new user when the user applies, but store the requested username as part of the application directly. When the user is approved by the admin, then create the backing DB user.

  6. dessalines commented on Feb 12, 2024

    @dessalines
    Member

    Yep it would delete their application as well, but that's not too big a problem IMO. I'd really like this process to be pretty hands-off tho, otherwise we're just adding pointless work for admins.

    So probably something like:

    • Delete all users that have been denied > week ago, on startup and in a scheduled daily job.
  7. informapirata commented on Feb 12, 2024

    @informapirata
    Author

    So probably something like:

    • Delete all users that have been denied > week ago, on startup and in a scheduled daily job

    Seems like a good trick to me. At the moment, however, this is an improvement compared to the current state.

    Out of curiosity, could you tell me if in your opinion the users who tried to register and who were not approved are included in the total user count of the system?

  8. dessalines commented on Feb 12, 2024

    @dessalines
    Member

    I believe they are unfortunately, but total user counts are pretty much useless. Active user counts are far preferred.

  9. informapirata commented on Feb 12, 2024

    @informapirata
    Author

    Active user counts are far preferred.

    Yes I agree. However, I was thinking about the fact that, for many instance administrators, the total number of users is a status symbol, a bit like the old Porsche parked in the yard. It no longer has the engine, but it serves to remind the whole neighborhood of how rich we were... 😁 😄 🤣

  10. added a commit that references this issue on Feb 12, 2024
    37e4978
  11. Security-Chief-Odo commented on Feb 13, 2024

    @Security-Chief-Odo
  12. informapirata commented on Feb 13, 2024

    @informapirata
    Author

    And the user in that case is not informed about the issue or timeline. Still seems to be a problem.

    This is a different type of problem, which concerns the transparency of immediate feedback to the rejected user. the current problem instead concerns exclusively the public exposure (and counting) of a created nickname.

    A specific issue has been presented for your problem, which is still serious but much less urgent

    LemmyNet/lemmy-ui#1096

    So a user applies, is denied, and can't reapply with the same username until at least a week later

    Still seems to be a problem

    Nah... If the "cryptospam_nft" user gets bounced and can't re-subscribe for a week, that's not a problem at all.

    The userid has particular importance in the fediverse and the problem does not lie in the impossibility of reusing it, but EXCLUSIVELY in the fact that it remains public even after its rejection and that it remains public in the impossibility of deleting it by the user

  13. added a commit that references this issue on Feb 15, 2024
    890565c
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't working

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions