Re: [patch] Auth to have case sensitive username matching in DB container
| From: | \[php\]Walter | 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