The default bug view has changed. See this FAQ.

Case-insensitive usernames should be enforced



Cloud Services
Server: Sync
8 years ago
8 years ago


(Reporter: anant, Assigned: anant)


Firefox Tracking Flags

(Not tracked)



(4 attachments)



8 years ago
Weave usernames should be case insensitive. We currently do not (completely) ignore case, here is what should be done:

1. Update LDAP master on (sm-proxy01) to go through all DNs and update them to be based on the correct uid.

2. Update the weaveserver code to lowercase all incoming usernames before passing them on to storage and authentication modules.

3. Update the mySQL DB to ignore case in its rows so that the calls to the storage module (which was changed in (2)) will return the correct set.

Comment 1

8 years ago
This should also address Issue #1 in bug #502721.

Comment 2

8 years ago
The registration script on sm-proxy01 should also been updated to generate correct DNs.

Comment 3

8 years ago
Steps 2 and 3 have to be performed by IT because we don't have direct access to the boxes that host the weaveserver code and mySQL DBs.
Created attachment 388334 [details]
php code to grab the users with uppercase letters

Should be run as 

php get_userlist.php > usernames
Created attachment 388336 [details]
Takes the users in "usernames" and lowercases them in the db

run after get_usernames.php has generated the list
Note that the two files above have blank usernames, hosts and passwords. You'll need to fill in those constants before running.
Your blog post mentions that people on the old system would have to sign up for a new account if they didn't remember the case of their username...  if they created a new account that used the same username, but a different case, wouldn't that cause duplicates when you try to down-case all of the existing entries?

Comment 8

8 years ago
I believe we currently case-insensitively check for conflicts, so it's not possible to have multiple users with the same string but different casing. Anant mentioned in our meeting that he's already double checked that there are no conflicts.
So I'll be on hand for this, but there's actually nothing for me to do. Here's the steps that need to happen on Sunday:

1) Take the two scripts here and put them on one of the frontends (or the master, if it has mysql_client running there). Edit the files to put the username, password and hostname of the mysql master into both scripts.

2) Shut down apache on the 4 front boxes.

3) run php get_userlist.php > usernames_temp  (this should take 5-7 minutes)

4) sort userlist_temp > usernames (not strictly necessary, but it'll make progress more obvious)

5) php user_rename.php

6) While 5 is happening, do an hg pull && update on the four frontends. Step 5 could well take an hour+

7) restart apache. We should be good to go at this point.

Comment 10

8 years ago
Created attachment 389168 [details]
LDAP Migration Script

This script uses command line LDAP tools to perform the uid/dn changes

Comment 11

8 years ago
Created attachment 389170 [details]
LDIF Generation Script

This script generates the LDIF required by ldapmodify


8 years ago
Attachment #389168 - Attachment mime type: application/octet-stream → text/plain


8 years ago
Attachment #389170 - Attachment mime type: application/octet-stream → text/plain

Comment 12

8 years ago
Required LDAP changes have been made.

Comment 13

8 years ago
Registration and password change scripts living on sm-proxy01 have been updated.
Database update complete and webheads restarted.

Logs are a little noisy, but nothing catastrophic, and the system is up.

Comment 15

8 years ago
After cleaning up a little hitch in the weaveserver code, looks like we're up and running. Many thanks to Zandr and Toby for spending their Sunday mornings on this :)

Will reopen if any regressions are found.
Last Resolved: 8 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.