On Wed, Jul 8, 2009 at 4:45 PM, PJ<af.gourmet@xxxxxxxxxxxx> wrote:
> Andrew Ballard wrote:
>> On Wed, Jul 8, 2009 at 11:53 AM, PJ<af.gourmet@xxxxxxxxxxxx> wrote:
>>> I have a couple of questions/comments re all this:
>>>
[snip]
>>> 2. Cleaning is another bloody headache, for me anyway. I have found that
>>> almost every time I try to do some cleaning with trim and
>>> mysql_real_escape_string and stripslashes wipes out my usernames and
>>> passwords. I havent' been able to use them when doing the crypt and
>>> encrypt stuff with salt. Without cleaning it works fine... so, I'm a bit
>>> lost on this.
>>> Specifically, this wipes out my login and password... (I know, this is
>>> old code, but it is supposed to work, no? )
>>> //Function to sanitize values received from the form. Prevents SQL injection
>>> function clean($str) {
>>> $str = @trim($str);
>>> if(get_magic_quotes_gpc()) {
>>> $str = stripslashes($str);
>>> }
>>> return mysql_real_escape_string($str);
>>> }
>>>
>>> //Sanitize the POST values
>>> $login = clean($_POST['login']);
>>> $password = clean($_POST['password']);
>>>
>>> When I echoes the cleaned $login and $password, they looked like they
>>> had just gone through an acid bath before being hit by katerina
>>> (hurricane)... ;-) rather whitewashed and empty. There was nothing left
>>> to work with.
>>>
>>
>> One thing to check - I'm pretty sure that mysql_real_escape_string
>> will only work if you have an open connection to mysql,
> It's always open... I think.. do you mean within the active script (the
> one I'm working on) ? Yes. yes, it's open.
As long as you have called mysql_connect() prior to using
mysql_real_escape_string() and the result of the former was a valid
connection resource, then the latter should work. Otherwise
mysql_real_escape_string() will try to connect with the default
credentials stored in php.ini, and failing that will generate an
E_WARNING that it was unable to connect.
Also, if there is no active connection, mysql_real_escape_string()
returns the boolean value false.
> the user_name was just plain alphabet soup... no special characters...
> the password, though, had some uppercase weirdos... like @$$
> (backslashing doesn't seem to help)... oh, well.... :-\
You shouldn't need to escape those specific characters in a MySQL
query, so running them through addslashes(), mysql_escape_string(), or
mysql_real_escape_string() would not escape them, and manually
escaping them would not produce desired results.
>> because it
>> uses that connection to figure out what character encoding
> Ohmygod.... not character encoding... it's such a mess for me. I try to
> only use utf8 but theres so much confusion with that that I have stopped
> thinking about it until a problem occurs... like in Firefox ... iget
> emails with the Western encoding and the utf8 so I often have to
> switch... and the prinouts don't follow either... lots of little black
> diamonds... a reat pita.
Here is a blog post that explains why it is important for
mysql_real_escape_string() to consider character sets.
>> is being
>> used so it can escape the string accordingly. (If unable to connect,
>> it should raise an E_WARNING.)
>>
>> I'm not sure why you would need to use @ with trim(), but that shouldn't matter.
>>
> Frankly, I don't know either. I borrowed the code somewhere; but I
> usually just 86 those @ts so I can see errors.
>> Otherwise, nothing in there should mangle the input.
>>
> mangle does as mangle can mangle... :-D
The function looks pretty straightforward. I'm curious what input you
are passing and how it's being "mangled" by the function.
Andrew
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
