Registration fails - username has a max_length of 30 #8

damianmoore opened this Issue Apr 7, 2011 · 16 comments


None yet

3 participants

I have been trying to get django-sync-server set up for a few hours. The problem seems to be that Firefox is generating a (random looking) username of 32 characters when I create an account from the in-built wizard (as detected by logging the 'username' variable just before creation).

Originally the line "if len(username) > 30 or len(data['password']) > 256:" was failing in the the exists() function in After changing this to a length of 32, the script failed further down where User.create_user() is called as the auth package has a max_limit of 30 for that field.

I cannot create an account, so this seems to be a major bug. There is also seems to be no easy fix as the django.contrib.auth package is limiting us.

I'm using Firefox 4.0 for account creation.

fladi commented Apr 7, 2011

Does the username you are trying to create contain any special chars, like "@"?

@fladi fladi closed this Apr 7, 2011
@fladi fladi reopened this Apr 7, 2011

As far as I can tell the username is auto-generated by the Firefox Sync wizard and is possibly a hash of the email/password inputs as it seems to have stayed the same for all my attempts at creating an account. The username is possibly an md5sum as it contains only numbers and lower-case letter characters (no symbols).

Perhaps this auto-generated username is a new feature of Firefox 4 and the older version of Firefox allowed you to specify your own username.

fladi commented Apr 7, 2011

So you are using the "@" character in your username, right?
Firefox Sync uses the regex "/[^A-Z0-9._-]/i" to check if it has to apply SHA1 to the username to convert it to a 32 char checksum, thus eliminating chars like "@" from the username. This is currently a static behavior in Firefox Sync and is necessary because of limitations on the official Mozilla Sync server.
The quickest solution would be to avoid using email addresses as usernames.

Sorry, I can clarify now. The version of sync now included with Firefox 4 does not have a field called username. Only email, password (twice), and server. See this video for the new registration screen.

After you enter these, Firefox creates a username for you that you never get to see but gets sent to the server. It is 32 characters long - no '@' symbol.

jedie commented Apr 8, 2011

btw. you should see the username on the "about:config" page. I have a setting called "services.sync.username". Don't know if you simply change it there, as a work a round.

IMHO it's boring, that sync used a SHA1 hash instead of a user name :(

I see two solutions:

  1. implement a own user model
  2. implement a "translation" model between SHA1 hash and django user account.

Don't know witch solution is better. Any hints?

Thanks for the suggestion jedie. I tried adding "services.sync.username" to my about:config (it was not there to start with) and registered an account again but it still failed and the debug output just showed the same username hash as before.

I may have a go at implementing your 'translation model' suggestion if I have time over the weekend as it would seem to be the least amount of work! ;-)

I can see why they use a hash for username as it makes registration easier for the user as they don't have to think about coming up with a name that nobody else chose. It's just unfortunate the hash is slightly too big.

fladi commented Apr 8, 2011

So if FF4 is enforcing the use of email addresses to has them to the username, this means django-sync-server is essentially broken for FF4. I'll see if I can get some information on why Django has this 30-chars-username limit in the first place.

jedie commented Apr 11, 2011

see now more solutions:

  1. implement a own user model
  2. implement a "translation" model between SHA1 hash and django user account.
  3. cut the hash to first 30 characters
  4. monkey-patch django's user model (ugly)
  5. retune mozilla guys to send email in plain text or reuse username
  6. talk to django developer to increase username lenght

any missed?

I thought about cutting the hash to 30 chars too. I'm sure it would allow enough possibilities for almost every user (I make it something like 36^30 combinations, which is massive) and is very simple, though getting an extension from the Django guys would be preferable.

I had a quick go at implementing a translation model between user and hash, one problem though is that you still need to give the User a username when you create it, so what should it be - a shortened version of the hash, something random, or it's auto incrementing id (requires saving twice) - yuck!.

jedie commented Apr 26, 2011

I implement a work-a-round by cutting the username to 30 characters.

Please try the current version and report ;)

I updated and your change has made things work perfectly. Thanks jedie.

jedie commented Jun 28, 2011

Does anyone really know how the has is generated in the sync client?

It seems not to be sha1(username) or sha1(email)...

EDIT: Found it here:

It's: base64.b32encode(hashlib.sha1(email).digest()).lower() :)

jedie commented Jun 28, 2011

I update django-sync-server to support the last version of sync (from firefox v5)...

So we have the problem with the username and the limit of django user model.

Now i would like to handle it in this way:

  • cut the hash, if a new user created.
  • build the hash from email, if user already exists.
jedie commented Jun 28, 2011

done with:

Please reopen this ticket if bugs related to this exist or any better solution...

@jedie jedie closed this Jun 28, 2011
jedie commented Jul 19, 2013

Today i reset all my sync stuff and recreate the user. It seems that this old bug still exists :(

Quick work-a-round for me was to cut the "services.sync.username" in "about:config"

@jedie jedie reopened this Jul 19, 2013
jedie commented Jul 22, 2013

btw. django 1.5 allows usernames with a max length of 254 characters. So the problem will fix with it.


  • add a fix for django <1.5 ?
  • only document this and add no work-a-round


Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment