LemmyNet
Denied applications cannot re-apply, cannot login, do not receive any information about their denial
Found a bug? Please fill out the sections below. 👍
For backend issues, use lemmy
Issue Summary
When a user applies to our instance and is denied, the user does not receive the denial reason. They are unable to login and unable to re-apply. Their user is created at the time of application, but no one can log into it.
Steps to Reproduce
- Create a test account on an instance with applications. Apply
- Deny the application
- Attempt to log in with the test account
Technical details
n/a
I think this is a backend issue. All the ui does in this flow is call the signup endpoint. The user is created on the server.
The end user cannot apply again if it is rejected, is this intended behavior? It seems they can't log in either. There's no communication to the person trying to register
Also users are reporting that they receive no notification of approval either. Some are getting emails who signed up with one, but some who signed up with an email are not. It appears very hit or miss, but I think notifications within the Lemmy platform would be incredibly useful.
However I'm not sure what is intended functionally so I'm not sure how much of this is a bug and how much is a feature request
When a user applies to our instance and is denied, the user does not receive the denial reason.
Getting in contact with them is the issue. I suppose we could email them the denial reason, if they provided an email. Open up an issue for that if you would. We already email them an approval notice.
Also, if they try to login after being denied, they will get a popup red toast / error message with their denial reason.
The end user cannot apply again if it is rejected, is this intended behavior? It seems they can't log in either. There's no communication to the person trying to register
They can apply again, but with a different username. That's very much inteneded behavior, because what you'd be asking for is essentially a chatroom / back and forth method of onboarding. This would be a massive amount of work to add to lemmy.
but some who signed up with an email are not.
@gaywallet I can confirm that an approval email was sent to me after being approved on lemmy.ml. According to docs and backend source code the backend should be handling email and always sending an approval email if the user has an email specified. The instances people who don't receive approval email apply on may have misconfigured smtp or the email could end up in spam. I think everything related to this should be on https://github.com/LemmyNet/lemmy
Also, if they try to login after being denied, they will get a popup red toast / error message with their denial reason.
as far as i can tell this is not a reliable fallback. my original test account which was denied doesn't apparently let me log in at all, meaning i cannot see the reason if an email fails to send--which in that case it did. i tested logins on Firefox and Chrome, and both have the same behavior for that account (attached below). i don't otherwise have issue logging in.
we also just tested this with a volunteer sysop of ours, and they're having the same problem with their account: no ability to log in.
They can apply again, but with a different username. That's very much inteneded behavior, because what you'd be asking for is essentially a chatroom / back and forth method of onboarding. This would be a massive amount of work to add to lemmy.
Massive amount of work how? Functionality wise it doesn't sound too complicated (perhaps not simple, but not very complex). It wouldn't be more work for the mods as they would re-evaluate the same amount of applications. It also seems like useful information that a user has tried applying before and what their application was before.
It seems quite bad user experience that the denied user doesn't get their preferred username and that that name permanently gets reserved and cannot be used again.
I think emailing if they have given an email seems like the best option. It would also help to specify that giving an email is a prerequisite for receiving a denial reason email (or approval email, or password reset email, for that matter).
Once a denied user tries to log in, they should be directed to a page that allows them to resubmit a their application.
@alyazabirze I just tested this, and have verified that yes, it is a bug. Not sure how it got in there... there's a chance this is fixed in main, but I'll leave this open until I can verify that it works.
Once a denied user tries to log in, they should be directed to a page that allows them to resubmit a their application.
Then a user can keep sending applications forever? Or it just allows one time?
This could also be implemented by allowing new registrations for the same user/email (using the same register form with password etc, only the backend api call needs to change). Much less work needed this way.
Then a user can keep sending applications forever? Or it just allows one time?
I think the ideal would be unlimited but the option to deny and block future applications. If that's too annoying to develop I think a single second chance would be good.
Ultimately we will want to clear up these usernames if they're rejected twice (or blocked as described above), so some way to delete these accounts after 30d of inactivity (or just automatically something like 30d after second denial) would be great.
Thats a lot of code for something that could also be fixed by editing only this logic to allow another registration if the previous one for that user was rejected. To block further attempts you could manually register that username yourself.
As I said, whatever's easier. A single extra attempt is perfectly fine with me.
I'm also fine with the ability to clear up accounts with multiple denials coming later, I'm mostly concerned about ensuring they get the message for denial and can try to reapply at least once.
@SorteKanin would you be willing to add this?
If you could give me a few pointers to the relevant portions of the code, I could give it a shot.
Then a user can keep sending applications forever? Or it just allows one time?
I don't see why not allow sending many applications. You can do effectively the same right now by just switching the username anyway. I don't see the difference.
Maybe a "deny forever" would be good, but then again, the user can still just apply again with a different username. So it really doesn't matter I feel like.
This could also be implemented by allowing new registrations for the same user/email (using the same register form with password etc, only the backend api call needs to change). Much less work needed this way.
But this would allow another user to sign up with the same username as someone who just tried to register right? So user A registers with username "Foo" and gets denied. Then user B registers again with username "Foo" (potentially even with a different password?). That seems undesirable.
Wouldn't "deny forever" just be the same as leaving the application pending anyway? I imagine you should only be able to re-apply if your application received a reply (approve or deny). So leaving it pending effectively stops the user from re-applying.
Wouldn't "deny forever" just be the same as leaving the application pending anyway? I imagine you should only be able to re-apply if your application received a reply (approve or deny). So leaving it pending effectively stops the user from re-applying.
Mostly just from a perspective of keeping things clean we would prefer not having to leave an application sitting there indefinitely if they're abusing the system. As you said it's quite possible for them to just spam registrations with new emails and usernames anyhow which is why I'm a fan of letting them continue to apply as many times as they'd like, but having some kind of block function could be useful to let someone know that we've made a final decision on them.
I also hope information on previous applications is pulled forward or visible in some fashion so the full context is available to the person reviewing the current application, but that's also more of a nice to have rather than a need to have.
as far as i can tell this is not a reliable fallback. my original test account which was denied doesn't apparently let me log in at all
I can confirm this, I just installed a lemmy_server and lemmy-ui instance and when you try to login to an acccount that is pending approval, the login page hangs with no error to the client.
I also hope information on previous applications is pulled forward or visible in some fashion so the full context is available to the person reviewing the current application
I also suggest that admin screen /registration_applications show the browser-string and the IP address from which the application came. ideally this page could be enhanced to allow sorting by IP address and application-time.
I think it would be useful to know if someone just did 20 accounts from the same IP address.
Lots of ways to improve this. Personally, here's what I'm thinking:
- Send email on rejection, optionally with reason explaining it.
- Optional (configurable): Block further registration attempts from said email (admin can unblock)
And then one of two would happen, but I don't know if it should be instance-level config decision or case-by-case:
- Delete the rejected account, so the username is free again, someone else can take it if original person doesn't/can't try again.
- Optionally tie rejected account's name to user email so a random person can't try registering with the same name.
If we can reach some sort of consensus, I can see about getting started on it soon (backend side anyway, someone else might have to do the UI).
@Carlrs @gaywallet @SorteKanin I'm having a look at this, though I'm working it out as I go. I agree that having an ongoing application process for denied applications is the ideal, but fixing the no email and tied up username problem seems like the first priority?
I'm seeing if I can sort that out first. Did you have any luck @SorteKanin?
The number one issue, to me, is being able to reject an applicant and ensure they get the denial reason. That needs to be sorted before anything else, and it needs to account for the fact that many users applied with no email.
After that the next priority would be allowing people to apply more than once with the username they applied with (at least 1 reapplication).
Only after fixes for both above would we want a tool for cleaning up stale usernames (reapplied max times, or have not reapplied in x days since last denial).
To be honest, this issue might stop be from ever using lemmy. I'm not even sure if my signup even worked at all - I clicked the submit button but I'm not sure if it was actually submitted.
I think this is a backend issue. All the ui does in this flow is call the signup endpoint.
No this is 100% a front end issue.
The problem is the user can't figure out what is going on. That needs to be fixed in the front end. Anything that can possibly go wrong with the signup process has to be visible to the user. The user also needs confirmation that it worked (and that can't be an email, because emails are unreliable).
You only get one chance to make a first impression. The signup process has to be a good experience.
I think there's certainly a UI portion to this bug, and there's improvements that could be made in the backend and in the UI.
For example, if you have a denied application, you literally cannot login, it just infinitely spins forever, which is not good UX. It should have some sort of message to the user about what went wrong.
