API: Way to check as non-admin whether an account's registration application has been accepted

Sjmarf commented 1 month ago

Requirements

[X] Is this a feature request? For questions or discussions use https://lemmy.ml/c/lemmy_support
[X] Did you check to see if this issue already exists?
[X] Is this only a feature request? Do not put multiple feature requests in one issue.
[X] Is this a backend issue? Use the lemmy-ui repo for UI / frontend issues.
[X] Do you agree to follow the rules in our Code of Conduct?

Is your proposal related to a problem?

When a user creates an account, the client could check whether the user's registration application has been accepted every 30 seconds or so. Then, the client could let the user know that their application has been accepted. This improves the experience, especially when the user didn't attach an email to their account - they would have no way of knowing when their registration has been accepted otherwise.

Unfortunately, this is (as far as I can tell) impossible to do without storing the username and password that the user signed up with locally on the client, and repeatedly attempting to login. This isn't ideal.

Describe the solution you'd like.

Add a boolean application_approved field to GetPersonDetailsResponse. Or maybe an enum with pending, approved and denied.

Describe alternatives you've considered.

Provide an auth token immediately when the user submits the application and allow the user to login, but not interact with anything. Then, allow the user to interact once the application has been approved.

Additional context

No response

Nothing4You commented 1 month ago

every 30 seconds seems unreasonably frequent.

regardless, you can just try logging in and it'll tell you that the application is pending, denied, or it'll log you in.

Sjmarf commented 1 month ago

every 30 seconds seems unreasonably frequent.

When logged in, Lemmy-UI checks the inbox every 30s. So checking the registration status every 30s, whilst the user is actively using the app, wouldn't unreasonable I don't think. It could be done less frequently, though, if there ends up being a rate limit or something.

regardless, you can just try logging in and it'll tell you that the application is pending, denied, or it'll log you in.

I mentioned this in my post. I’d rather avoid doing that because it requires me to store the user’s raw password on the device. At the moment we only need to store the user’s auth token. This is more secure because you can't delete your account or change password using just the auth token. A way of doing this without requiring the password every time would be nice.

dessalines commented 1 month ago

I'm not sure this is a good idea, especially as we should be focusing on notifications being push-oriented, not poll-based. And registration applications already send an email when they're approved, which is the correct way to handle it.

Sjmarf commented 1 month ago

I'm not sure this is a good idea, especially as we should be focusing on notifications being push-oriented, not poll-based. And registration applications already send an email when they're approved, which is the correct way to handle it.

Indeed, but not all instances require an email address to sign up. In that situation, there would be no way for the user to know when they've been accepted.

I mentioned an alternative solution that wouldn't require the user to log-in again at all, but would be more difficult to implement I imagine:

Provide an auth token immediately when the user submits the application and allow the user to login, but not interact with anything. Then, allow the user to interact once the application has been approved.

Nothing4You commented 1 month ago

I'm kinda wondering if this could maybe be implemented in a different way, by no longer exposing users that didn't have their application approved.

Similar to how deleted users are not returned by the API, users pending registration could also be not publicly displayed.

This could also have the side benefit of other apub software not being able to federate the account (if it got e.g. mentioned for some reason) and gets deleted after the application is rejected, which then leads to the other software potentially having a no longer existing public key for the actor.

I don't think there's any reason to expose unconfirmed users to anyone when applications are required.

This might change in the future if there comes some kind of vouch system, but for now this could be an easy solution that also satisfies this request. It could also be considered to return an API error indicating application pending or application rejected for those requests to /api/v3/person or the apub request to /u/$user.

dessalines commented 1 month ago

I'm pretty staunchly against a "half-approved" or "read-only" account states, because of the complexities that would add.

If the server is public, they can just wait for an account approval, or get an email on approval, and browse the site in the meantime. If its private, you probably wouldn't want a "half-approved" state that could view your server without approval anyway.

Nothing4You commented 1 month ago

Just to be clear, my proposal wouldn't involve authentication. It would be unauthenticated requests against /api/v3/person?username=dessalines, which could return an error like application_pending or application_rejected when the user is not approved.

DraconicNEO commented 1 month ago

I'm pretty staunchly against a "half-approved" or "read-only" account states, because of the complexities that would add.

If the server is public, they can just wait for an account approval, or get an email on approval, and browse the site in the meantime. If its private, you probably wouldn't want a "half-approved" state that could view your server without approval anyway.

You could just have the half-approved or read-only state lock you to the dashboard without letting you browse feeds or posts, this is what Mastodon does in their setup, and if you want to browse without an account you can simply sign out and get access.

LemmyNet / lemmy