RE: [PEAR] Wierdness with the Auth class... Solved!

I am using the following version of the Auth class: $Id: Auth.php,v 1.29 2002/02/07 11:07:12 mj Exp $ I am also using the following version of the DB.php container. $Id: DB.php,v 1.11 2002/01/10 09:40:34 mj Exp $ The problem is now solved, but let me explain what was happening because it may be that we consider adding a thing or two to accommodate situations like mine in the future (which I have outlined under the explanation below). The current client I am working with wanted his system to not care about wether we were checking against lowercase values or uppercase values for the password and username fields in the database. So to accommodate him and this risky request (I know this is not really the best way to go), I had rewritten the 'assignData()' function to make the internal '$this->username' and '$this->password' fields lowercase. I had not however, taken this into account in the fetchData function. The fetchData function was grabbing values out of the database and making a comparison withouth converting the strings to lowercase first, thus leading to the authentication failure. As for the print_r($query), not displaying the results, as mentioned originally, that was a result of me, once again, trying to accommodate this particular client. You see, I have other applications I use this class with and have seperate copies of the Auth Class installed. Well the Auth class itself, when 'requiring' the container class, looks to the default Auth/Container path for the DB.php file. I had not modified that path to reflect the custom version of the Auth class for this client. So any changes I made to my local custom copy of Container/DB.php, were not happening because that file was not being used in the first place. So, in light of all this, there are a few suggestions to consider for future revision of the Auth class I would like to see that would have made my life easier. In other words, some suggestions to consider for making the Auth package a little easier to integrate into pre exisiting systems. 1) Add a method that allows the user to set a path where the DB.php and other container files will reside when instantiating the class. The default will simply be where the files are in the distribution now. 2) For those who (and I hesitate to say it) are using plain text passwords in their database, an option for the class to not automatically assume we are using md5 hashed passwords. Or even a way to accommodate those using MySQL's PAWWORD(), type encryption. 3) At the least, perhaps we should consider adding the trim function in the 'assignData()' method for incoming data, as well as other checks for malicious code being passed, as well as a trim function on the fetchData(), method for data coming out of the database before making a comparison. Thanks everyone for the efforts so far, Sincerely, Alan T. Miller LIMBOURG Arnaud said: > Hello, > > What version of Auth are you using ? > > Try a PEAR::setErrorHandling(PEAR_ERROR_DIE); > > this stop execution on any pear error. Then you might be able to see > what is wrong. If this does not work i would try putting a print_r on > the "query" method in Auth or Auth_Container_DB. > > Another thing, are you using Oracle ? There was a discussion on the list > about oracle which apparently fills with extra spaces when using CHAR so > it could be a problem. But it should do it for every user not just a > few. > > At last a print_r($this) before the fetchdata method and see how the > object looks. And get back to the list ;) > > Arnaud. > >> I recently implemented the PEAR::Auth class in an application >> and for the >> most part it works pretty well. I set it up to check against >> our current >> database of users. I set the field names as instructed in the >> documentation to match our database fields for the username >> as well as the >> password. >> >> I had successfully tested it against a half dozen known >> accounts and it >> worked fine. However, once we went into a user testing phase >> people were >> complaining that our system would not allow them to log in, >> not everyone >> just a few people. For those accounts who could not log in, I >> check their >> username and passwords manually in the database and sure >> enough they are >> there in the database as they should be, but for some unknown >> reason, the >> Auth class fails to authenticate those accounts. >> >> The problem is consistent on two different development >> machines running >> different platforms. Same data different machines, same result. >> >> Now I am trying to debug this issue, and the first thing I >> wanted to check >> was the actual query that the Auth container is sending to >> the database, >> so I did my usual 'print_r' on the query before it executes the query >> inside the 'fetchData()' method of the DB container, and I receive no >> results on screen. >> >> Overall, I suspect that there is an issue here with the datatypes, or >> maybe extra space charachters on the database fields >> themselves, but am >> not clear at this point on how to at least print out the >> query that the >> Auth class is creating, and where the Auth clas is failing to >> authenticate >> these particular users. >> >> Any reason for this, or suggestions on what to try from here >> that someone >> can point out? >> >> Thanks in advance. >> >> Alan >> >> >> ------ >> Alan T. Miller >> amiller@hollywood101.com >> http://www.alantmiller.com >> >> >> >> >> -- >> PEAR General Mailing List (http://pear.php.net/) >> To unsubscribe, visit: http://www.php.net/unsub.php >> > > -- > PEAR General Mailing List (http://pear.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php ------ Alan T. Miller amiller@hollywood101.com http://www.alantmiller.com