Closed Bug 808827 Opened 12 years ago Closed 12 years ago

Randomized username 40 chars and username only allowed to be 30

Categories

(Participation Infrastructure :: Phonebook, defect)

x86
macOS
defect
Not set
normal

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: peterbe, Assigned: giorgos)

References

Details

This screenshot, I hope, explains it all: 
http://cl.ly/Kfwu

Steps:

1. Sign in, type in First, Last, etc. 
  (no Username field shown of course)
2. Click next. 
3. I failed to enter Providence and Country on the last page right before clicking Create if that matters.
4. Click Create

I was able to get past by simply chopping off the last 10 characters of the randomized username for me.
Note:

I could not reproduce this.

I tried registering with a new broswer id account using booboobenny@gmail.com

The username was pre-populated with booboobenny.

I tried to see if the error condition could cause this, I removed my username and clicked save, this also did not cause the above.
Assignee: nobody → giorgos
Blocks: 752997
One additional item to check.

It looks like there was an existing account with peterbe as the username.

Perhaps the crazy hash gets added if the username already exists?
Status: NEW → ASSIGNED
Commits pushed to master at https://github.com/mozilla/mozillians

https://github.com/mozilla/mozillians/commit/30cdb0fc7b3cead21634c23b68d8c1bff37ae207
[fix bug 808827] Use digest and base64 on calculated usernames to avoid crossing 30 char limit.

https://github.com/mozilla/mozillians/commit/e705506fa4a0a9dae11b047688ca22dd5f37c57c
Merge pull request #342 from glogiotatidis/808827

[fix bug 808827] Use digest and base64 on calculated usernames to avoid ...
Status: ASSIGNED → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Nice catch Peter, thanks for reporting. Indeed the issue appears when the username already exists in the db.
The hash is a really bad username, if the username is taken can we alert the user with an error and have them choose one.

We can also implement post api.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Ben:

Due to the way Persona works, when you login to our website for the first time, you get the 'register' view but you already have an account. Thus we need to generate some sort of username. 

So to get this username, we first try to extract a username from the email address used to login to our website and if that fails (i.e. there is another user with the same username) we fallback to the hash. 

I agree that we can display something nicer to the user and I suggest that we add this bug to the UI/UX re-design milestone.
Perhaps my memory is failing me but I noticed a different behaviour which worked better. 

I signed in as `mail@peterbe.com
(oops, hit Enter too quickly)

...

I signed in as `mail@peterbe.com` and it filled in the username field as `mail` (which makes sense) but when I clicked to create the account it complained that the username was already taken. 

I think that if username (from the email address) isn't available it should simply just show the User Name field as empty. The hash never makes sense. Look at this for example: http://cl.ly/Kg7m
If the username wasn't important and never displayed then I'd be all for using a hash.
Ok ill close this one as it was specific to the hash being too long. I will open a new one capturing removing the hash as the default username.
Status: REOPENED → RESOLVED
Closed: 12 years ago12 years ago
Resolution: --- → FIXED
The 'mail' username is on blacklist, thus you got an error. There isn't a user with 'mail' username and therefore you didn't get the hash displayed.

I agree that the whole procedure is broken. Ben please create another bug as you suggest, that blocks the UX/UI re-design milestone.

Thanks!
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.