Try again, and include the actual link this time, dummy. :-)
On Wed, Jul 8, 2009 at 5:30 PM, Andrew Ballard<aballard@xxxxxxxxx> wrote:
> 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.
http://shiflett.org/blog/2006/jan/addslashes-versus-mysql-real-escape-string
>>> 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
