Username Not Available when signing up twice, first incompletely

Found a bug in 2.1.0.beta2 (derived from page source) from which may be an edge or corner case but nevertheless it should be reproducible. It impacts the user sign-up flow for individuals who bail on SSO in favor of an email sign-up. The impact is that an available username becomes reserved by the system.

Here’s a visual of the bug, which is preventing me from signing up for community.bitwarden.com with my preferred username:

Impacted users:

  • Users who decide not to use SSO and bail on the process.

To reproduce:

  1. Navigate to community.bitwarden.com (or preferably a test server running 2.1.0.beta2).
  2. Attempt to sign-up for an account using SSO with GitHub.
  3. Do not complete registration by email.
  4. Attempt to sign-up again by email.
  5. Observe email not received.
  6. Refresh with cache clear.
  7. Attempt to sign-up again by email.
  8. Observe username unavailable.

I’m not aware of model state is at this point in the back-end but I’m guessing there’s a username in a users table without an associated email address or with an incorrect email address, and possibly erroneously linked to a GitHub account. Only way I can see to get my username back is to contact the forum admins or wait and hope there’s some kind of reclaimation process to purge users who didn’t complete the sign-up in full.

Isn’t that kind of an edge case? why would someone signing up from github all of a sudden change their mind and start the sign up process all over again?

I’m quite sure that there should be threshold after which the username will be available again (in case your system has created an account which isn’t activated yet) but this isn’t a case that is gonna happen on a regular basis!

and 11 Steps to reproduce?

Would like to add to this, This can potentially be by design too as just in case the Github user changes his mind and wants to sign up again then they would be upset that their username (which was available) has all of a sudden gone unavailable. There can be network issues too in case a user was authorizing and their network went down?>

As stated above, this is probably an edge case.

Log-in flows are complex by nature. It could be reduced with loss of detail.

That’s in part why I opened this bug. It’s not clear that will actually happen.

I can probably confirm what happens! … After the period you’ve stated in : purge_unactivated_users_grace_period_days
the username should become available again.

I still don’t understand how much rare it would be for someone to all of a sudden ditch social sign in and start the registration flow again.

3 Likes

I’m not sure myself either. In my case I simply didn’t have access to my GitHub email address to confirm login and choose to use an email I did have access to.

Thanks for making me aware of this. Not sure what the default setting is or if the admins of the forum have customized it but I’ll just wait and try to sign-up again once purged.

Note on the above, I’ve reduced the number of steps to reproduce from 11 to 8.

If your address is verified on github then you shouldn’t be receiving a confirmation email from discourse.

And I’d stress again this all more or less looks like it is by design not by fault so I think this belongs to support not bug.

https://github.com/discourse/discourse/blob/master/config/site_settings.yml#L441-L442

2 Likes

Given the purge process is in place I’d say this issue isn’t worth anymore attention. Thanks to @itsbhanusharma and @Mittineague for your help leveling up my understanding.

And to satisfy any curiosity I typically choose not to use SSO in favor of password management in most cases and have found a way to quiet GH email notifications on my account:

1 Like

Yes, this is as designed, and the above is true. The default for that setting is 14 days though.

Your workaround is simply to complete the login via GitHub.

2 Likes

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.