mbin icon indicating copy to clipboard operation
mbin copied to clipboard

Add option for new accounts to require admin approval

Open e-five256 opened this issue 1 year ago • 3 comments

Is your feature request related to a problem? Please describe.

Right now instance owners still are lacking some measures to fight back against spam waves. One that may help is adding an option for account creation to require admin/global mod (maybe) approval before the account can be used

Describe the solution you'd like

We might want to investigate how other platforms do this. One major consideration is, if enabled, should accounts be made (and the address for that account name burned)? Or should the accounts be held in a separate state until admin approval, at which point they are created and the fediverse can find them.

Assuming we don't want to create the accounts in a way that uses the address forever before approval:

  • Potentially a new table like users_awaiting_approval with columns of the username, hashed_password, email etc that are required to create an account
  • If enabled, registrations go to this new table instead of the user table, login says awaiting approval if possible (if not, maybe user does not exist is fine at least for first pass)
  • New admin UI to list entries awaiting approval
  • Ability to accept or reject those requests
    • On accept, actually make the public.user entry, email the user
    • On deny, email the user they have been denied?

If instead we don't care if the username is burned, another possible implementation is

  • New column on public.user such as requires_approval = true
  • Block login if the flag is true
  • New admin UI to list users where requires_approval is true. New index on where requires_approval is true to make the query fast
  • Same as above on accept/deny emailing user

Describe alternatives you've considered

There might be other options to curtail spam that are lower hanging fruit, if people can think of them. We could also just do something like an admin option to automatically ban users on registration, so admins could then unban as a form of "approval". The flow would be confusing for users, but it's all tech that exists today so would be faster to implement

e-five256 avatar Apr 25 '24 20:04 e-five256

This issue is stale because it has been open 50 days with no activity. Remove stale label or comment or this will be closed in 6 days.

github-actions[bot] avatar Jun 15 '24 02:06 github-actions[bot]

I think we do need it and we have to create the users right away. Simply because we have to reserve the username. What would happen when the user then already exists when an admin approves an account... Additionally I think that the solution in the user table is just so much easier :D

BentiGorlich avatar Jun 19 '24 10:06 BentiGorlich

I think we do need it and we have to create the users right away. Simply because we have to reserve the username. What would happen when the user then already exists when an admin approves an account... Additionally I think that the solution in the user table is just so much easier :D

OK fine, but in that case an additional column should be present that it isn't active yet. So when approval feature is disable the users are active by default. And otherwise the active column should be false, and only set to true after approval?

Then we also need to make sure that the user isn't listed when active (or whatever the column name will be) is false. And the user can't login if active is false. etc.

melroy89 avatar Jun 20 '24 15:06 melroy89