Opened 16 years ago

Last modified 10 years ago

#20 assigned defect

Uppercase usernames create new accounts

Reported by: rjl Owned by: rjl
Priority: normal Milestone: post-1.0.3 triage
Component: General Version: 1.0.0 RC5
Severity: normal Keywords: uppercase upper-case case-sensitivity postgresql username


From Chris Paul:

We just noticed it actually that if you log in with any uppercases characters, it will work but then subsequent logins will have to match exactly.

Apparently, Maia generates a new ID for the account. Interesting that the white/blacklists and contents of the quarantine now are assigned to the new login.

Subsequent logins with all lowercase will work but there will be no quarantine/ no white/black-lists.

We're using LDAP auth with PostgreSQL.

Change History (9)

comment:1 Changed 15 years ago by dmorton

According to RFC's, the username portion of an email address *may* be case sensitive, and so it should be treated as such.

Should we have a system config option to specify whether to be case sensitive?

comment:2 Changed 14 years ago by dmorton

  • Milestone 1.0.0 RC6 deleted

comment:3 Changed 13 years ago by dmorton

  • Milestone set to 1.1.0
  • patch set to 0

[ Mysql is not

case sensitive]

[ Postgresql is case sensitve] ...

For the 1.0 series, we could add an optional config value to config.php to force lowercase comparison or lowercase storage....

1.1 series should be a config option in the auth table.

comment:4 Changed 12 years ago by rjl

  • Component changed from PHP scripts to General
  • Milestone changed from 1.1.0 to 1.0.3
  • Status changed from new to assigned

This bug affects address-handling throughout every part of the Maia system except for amavisd-maia (which uses $localpart_is_case_sensitive to adjust the case of user-supplied addresses). In particular it is important to control how addresses are written to the database in the first place--they must be written exactly as they are going to be searched for later. This means applying amavisd-maia's case-sensitivity rules to other Perl and PHP scripts as well, so that raw addresses get adjusted before being written to the database. This is especially true for, which could otherwise be writing a batch of raw addresses to the database without considering the local case-sensitivity convention, but it also applies to the administrative "add user" feature--any place we do INSERTs on the 'users' table, really.

comment:5 Changed 12 years ago by rjl

Changeset [1235] implements fixes for, including a --preserve-case flag and $preserve_case default setting for maia.conf. By default, e-mail addresses are treated as case-insensitive and are lowercased automatically. If the --preserve-case flag is set or $preserve_case is non-zero, the username portion of e-mail addresses will be treated as case-sensitive.

comment:6 Changed 12 years ago by mortonda@…

It seems insane to even allow case sensitivity... Bob@… and bob@… - who would ever think those should be different accounts?

But if we were to lowercase everything before storage, it *could* break when rescuing email, since it might not be accurate. I doubt this would ever happen, but...

OTOH, this means that whenever we search for an email address or username, we need to force it to compare insensitively.

$select = "SELECT id FROM maia_users " .
                  "WHERE user_name = ?";


$select = "SELECT id FROM maia_users " .
                  "WHERE LOWER(user_name) = LOWER(?)";

Is this bad on performance? I suppose it shouldn't cost too much extra to do a simple strToLower() call...

But it means a long code review to find every instance where this could be an issue. :(

Hey, I just found a new development: citext data type ... I think that might be a nice choice...

comment:7 Changed 12 years ago by mortonda@…

[1328] block a login if it is about to yank away a users row from another account. Looking at the 1.1 trunk, I don't think it is an issue. postfilters can easily do the proper lowercasing if needed.

comment:8 Changed 11 years ago by mortonda@…

Note of interest: while testing some code which involved changing the collation in mysql, it gave me this in domainsettings.php:

#1267 - Illegal mix of collations (latin1_swedish_ci,IMPLICIT) and (latin1_general_cs,IMPLICIT) for operation '=' 

So mixing collations means we'll have to do some explicit casting elsewhere too. blech.

comment:9 Changed 10 years ago by mortonda@…

  • Milestone changed from 1.0.3 to post-1.0.3 triage

This is safer now, but the final solution is still elusive. let's keep the issue alive for future versions...

Note: See TracTickets for help on using tickets.