Patch #4732

Make login case-insensitive also for PostgreSQL

Added by Marcel Waldvogel almost 13 years ago. Updated over 12 years ago.

Status:ClosedStart date:2010-02-03
Priority:NormalDue date:
Assignee:Eric Davis% Done:


Category:Accounts / authentication
Target version:1.0.0 (RC)


When using MySQL as the backend, it will automatically do case-insensitive comparisons.
For a PostgreSQL database, however, trying to log in with different capitalisation will result in either of the following error messages (paraphrased):
  1. "User unknown" (when the user is not in LDAP or LDAP is not configured)
  2. "User with this email address already exists" (when there is such a user in LDAP and automatic addition is enabled; this is more confusing than "User unknown")
This patch resolves this problem for all systems, trying to use indices as much as possible:
  • For MySQL and PostgreSQL backends, it will even avoid table walks on successful attempts (there might be a table walk for unsuccessful logins with MySQL backend, depending on how MySQL's query optimiser works. Avoiding such a table walk for sure would require testing for the adapter in the controller, which I find pretty ugly).
  • For sqlite, it is likely to cause a table walk when capitalisation differs (but I would expect anyone using sqlite as a production backend will have few enough users).

An alternative would be to downcase the login name always, but this would require updating existing databases and might upset users who are used to seeing their name in mixed case.

case-insensitive-login.patch Magnifier (1.87 KB) Marcel Waldvogel, 2010-02-04 00:26

Related issues

Related to Redmine - Defect #2473: Login and mail should not be case sensitive Closed 2009-01-08


#1 Updated by Stanislav German-Evtushenko over 12 years ago

Issue #2473 is similar to this one.

#2 Updated by Eric Davis over 12 years ago

  • Status changed from New to Closed
  • Assignee set to Eric Davis
  • Target version set to 1.0.0 (RC)
  • % Done changed from 0 to 100

A patch was committed in r3807 as part of #2473 that resolves this.

Also available in: Atom PDF