[ic] logged in case insensitivity issue - current Standard

Paul Jordan paul at gishnetwork.com
Sat Dec 12 16:25:47 UTC 2009


> On 12/12/09 17:17, Paul Jordan wrote:
>> It appears that as standard ships, a customer login is not case
>> sensitive. However, in order to access their order history (detail
>> page), there is a username comparison to validate the user, it's on
>> query/order_detail.html. The comparison IS case sensitive, so for
>> example, if someone logs in as LAdams, instead of ladams, or something
>> more likely - to issue a return as u01234, instead of U01234, they'll be
>> met with an user violation error when wanting to see the detail of their
>> past orders.
>
> This is actually coming from the DB itself.  MySQL comparisons are
> case-insensitive whereas PostgreSQL are case-sensistive, so you will
> find that if you are running PostgreSQL the login will actually be case
> sensistive.  I think that we should fix the issue to be consistent
> across dbs and also fix the behavior to be consistent in IC itself.  So
> we need to answer the following questions:
>
> 1.  To make the behavior consistent across DBs should we adopt the MySQL
> case-insensitive behavior or the PostgreSQL case-sensitive behavior?
>
> 2.  Should we fix this in the record_exists() db method or elsewhere?
> What about other db functions?
>
> 3.  Alternatively we can fetch the username with correct case from the
> DB during login and replace the passed username with that.

It is my opinion that in the case of usernames, everything should be case 
insensitive. I mean no system is really going to deal with it's customers 
and say, are you LAdams, or ladams, or ladaMs. Passwords will get a boost 
from case sensitivity, but not usernames, that would just be confusing.

I'm all for eventually making all uses of username in perl modules lowercase 
first. Although #3 seems just fine to me.

Paul




 




More information about the interchange-users mailing list