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

From: Date: Thu, 20 May 2004 14:18:30 +0000
Subject: Re: [patch] Auth to have case sensitive username matching in DB container
References: 1 2 3 4 5 6 7  Groups: php.pear.dev 
Request: Send a blank email to pear-dev+get-29453@lists.php.net to get a copy of this message
"Yavor Shahpasov" <yavo@siava.org> wrote in message news:40AA217E.1060108@siava.org... > Hello Walter, > > if your patch is to be rejected by any one it would be up to me to do > it. it would be nice if in future you would post a diff instead of code > with comments, it is easier to follow i guess. Yes, my applogies. I'll add that to my list of things to learn how to do. > I took over maintenance of auth some time ago, I assume that the change > password feature was rejected by martin. Yep. And I understand the reasoning behind it. > I too agree that user managment should be left out of auth > but since the add / remove user methods are there already I > desided to stretch the line just a bit more. The slippery slope of rationalization. > I believe the only correct way to solve this is to force the username to > be in a certain case (upper or lower). I wasn't so sure of that "requirement". That's why I added that as a property flag, for those who se eit that way. > Checking if the return value is the same as the requested value is for > me wrong and should be handled by the database. > > If there is any misrepresentation of information it comes from the > database. ...That is the detabase fault and should be taken care > there. On one hand, I can see that. But what about those that have no control over the database, or whatever the "container" is? > The best solution you have is writing a custom auth container, it is > only a few lines of code. I guess I don't follow that. Since the patch submitted modified the DB container to handle DB that don't work properly. And yes, a new subClass of container:db could be created. But that would assume that the developer realized that his/her DB had this "feature" (case-insensitive matching) so they could use the new subclass. But, as I did, if they don't know that this is possible (case-insensitive matching) then they could spend several days trying to trace why the testing ID does not work, as I did. The main Class was changed to deal with a new property, which could be handled by the new 'advancedsecurity' property. So the only thing being changed is PEAR:Auth:Container:DB.php. Not having access to other "container" types, I can't speak for the others. > As always everything is open for discussion I guess no one sees any value to this discussion or the idea in general. Thanks for your time. Walter

« previous php.pear.dev (#29453) next »