No subject

> On 12/12/09 17:17, Paul Jordan wrote:
>> It appears that as standard ships, a customer login is not case=20
>> sensitive. However, in order to access their order history (detail=20
>> page), there is a username comparison to validate the user, it's on=20
>> query/order_detail.html. The comparison IS case sensitive, so for=20
>> example, if someone logs in as LAdams, instead of ladams, or=20
>> something more likely - to issue a return as u01234, instead of=20
>> U01234, they'll be met with an user violation error when wanting to=20
>> see the detail of their past orders.
>
> This is actually coming from the DB itself.  MySQL comparisons are=20
> case-insensitive whereas PostgreSQL are case-sensistive, so you will=20
> find that if you are running PostgreSQL the login will actually be=20
> case sensistive.  I think that we should fix the issue to be=20
> consistent across dbs and also fix the behavior to be consistent in IC=20
> itself.  So we need to answer the following questions:
>
> 1.  To make the behavior consistent across DBs should we adopt the=20
> MySQL case-insensitive behavior or the PostgreSQL case-sensitive behavi=
or?
>
> 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=20
> 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 customer=
s and say, are you LAdams, or ladams, or ladaMs. Passwords will get a boo=
st from case sensitivity, but not usernames, that would just be confusing=
.

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

Paul