Re: [patch] Auth to have case sensitive username matching in DB container

There are databases which are case sensitive when doing string comparison and others which are not. case insesitive DB's were a bad practice started by MS (i think). I believe access and SQL Server consider this to be true 'Joe' == 'joe' i think that that is generally ok, sine (it should) make 'joe' unique no matter what the case is assuming a valid constrain is enforced. More dangerous for me are the case sensitive database which would allow you to create user 'Joe' and a second user 'joe', and to make it really fun you might just throw 'jOe' in the mix. the above scenario can cause a lot of confusion. it is a good practice therefor (IMHO) to agreen on a case for usernames and enforce it programatically. In the light of the below discussion, i think there should be an option which makes sure that the user name is sent to the database in a single case ex $auth->setUsernameCase(UPPER|LOWER) Let me know your comments Yavor phpWalter wrote:

-----Original Message----- From: Ian Eure [mailto:ieure@php.net] Sent: Thursday, May 13, 2004 12:43 AM To: pear-dev@lists.php.net Cc: Yavor Shahpasov; [php]Walter Subject: Re: [PEAR-DEV] [patch] Auth to have case sensitive username matching in DB container On Wednesday 12 May 2004 04:04 pm, Yavor Shahpasov wrote:

do you mean that 'Joe' != 'joe' where joe/Joe is the username or have i completly missed the point. What is your target database.

It appears that for some (broken?) databases, doing a SELECT WHERE usernamecol = 'jOe' will match a row where usernamecol = 'joe'.

This is my understanding as well. Never the less, this needs to be handled.

The submitter doesn't specify what database they are using,

Yes, sorry, oversight on my part... mySQL

but this certainly seems like incorrect behavior.

Again, I agree, but...

I know that PostgreSQL won't do this, and MySQL only does case-insensitive searches if you use LIKE.

That is good to know, but... This is the query from Auth:Container:DB.php

       $query = "SELECT ".$sql_from.
               " FROM ".$this->options['table'].
               " WHERE ".$this->options['usernamecol'].
               " = '".$this->db->quoteString($username)."'";

The patch verifies that the username returned from the database matches the requested username exactly.

That's the idea.

Seems like a database bug to me, and not a BC break to make sure that 'jOe' = 'JOe' and not 'joE'.

I don't follow this. "not a BC break"?? What does that mean? Do you mean that this patch would break BC? Please explain to me how, as I don't see it. I thought that by defaulting this case sensitive flag to false BC would be maintained. And if you wanted/needed case sensitivity, you, the developer, would turn it on. Or do you mean that this patch does *not* break BC? Or am I not seeing something that is obvious to you? Thanks for your comments. Walter

-- Yavor Shahpasov yavo@siava.org Linux is not The Answer. Yes is the answer. Linux is The Question.