Fix usernames being case sensitive

[mgaffigan]

Closes #122 / original #5569 by:

• Normalizing username after login success
• Using case-insensitive comparisons in DB

Implementation Notes:

• Used LOWER() in pgsql instead of collation to avoid having to rely upon system defaults or database defined collation. Presumably table is not so large that sargability is a concern (since we're loading the full table to the client on each login)
• No collation support seems to exist in Derby, so LOWER()
• MSSQL and MySQL already case insensitive by system default

[david-labs-ca]

So, John.doe and john.doe are same person?

[mgaffigan]

@david-labs-ca, there's discussion on the original ticket.

I think the world at large usually assumes usernames to be case-insensitive. It's also just plum broken on several case-insensitive database engines in main, so if the decision were to make them case sensitive, a change would still be required.

[tonygermano]

@david-labs-ca, there's discussion on the original ticket.

I think the world at large usually assumes usernames to be case-insensitive. It's also just plum broken on several case-insensitive database engines in main, so if the decision were to make them case sensitive, a change would still be required.

I get angry any time I encounter a system with case-sensitive usernames. I expect to always be able to type my username in all lowercase, regardless of how the admin added it to the system.

[tonygermano]

suggestion: don't assume anything about which charset, collation, or locale are in use

I think it would be a good idea to use LOWER(USERNAME) = LOWER(#{username}) across all databases, and if that returns multiple results because a case-sensitive collation is in use and there are similar names, then fall back to USERNAME = #{username}.

[mgaffigan]

@tonygermano
Re: collation, at a certain level every string compare is done in the context of a collation, implicit or explicit. UPPER and LOWER also produce sargability challenges. In my experience, you will make more DBA friends with COLLATE than with LOWER(...). The only reason I did not use COLLATE uniformly is to avoid DDL changes.

Re: existing users, I've added a fallback to match case-sensitive if multiple users match. Adding a new user with a different casing fails with com.mirth.connect.client.core.ControllerException: Error adding user: username must be unique

[tonygermano]

@tonygermano Re: collation, at a certain level every string compare is done in the context of a collation, implicit or explicit. UPPER and LOWER also produce sargability challenges. In my experience, you will make more DBA friends with COLLATE than with LOWER(...). The only reason I did not use COLLATE uniformly is to avoid DDL changes.

@mgaffigan I don't think the PERSON table is expected to get very large where a scan would be a problem, and this seems evident because there isn't an index on USERNAME. In this case, I think it's better to be safe and use the standard SQL function without making assumptions about the environment rather than going for performance. LOWER should work across all databases respecting their current collation, character encoding, and locale.

This is completely up to you, but if you want to address this issue, too, it's related nextgenhealthcare/connect#3386