Oh. I had no idea that you had re-enabled makeSafe(). You almost
certainly do not want to do that, it was disabled because it was
broken.
makeSafe() likely will never use addSlashes() since that protection
was intended to make variables safe for use with sql.
Future implementations of makeSafe() will instead perform some magic like:
$iNumeric = makeSafe($iNumeric, FILTER_NUMERIC);
Chris
On 6/25/06, Tony Lambregts <[EMAIL PROTECTED]> wrote:
Chris Morgan wrote:
>>> 5.) If you add a hyperlink in a note it is broken with makesafe()
>>> turned on.
>> I'm not sure this has anything to do with makeSafe(). Right now makeSafe()
>> is effectively disabled and I've carefully reviewed the changes to
>> addAppNode.php but I can't see how any of the changes broke notes.
>>
>> On my local machine after previewing a note I'm seeing any url I put in
>> prefixed by the current page url. On the appdb when previewing everything
>> appears to be working correctly.
>>
>> I think this may be a legit bug with the injection changes and I'll fix it
>> before committing.
>>
>
> Just tested again here with the injection changes and hypertext(tested with a
> url) in notes looks good to me.
>
> Chris
>
>
>
let me clarify that this is with makeSafe() turned on. IE male safe defined as
this:
function makeSafe($var)
{
$var = trim(addslashes($var));
return $var;
}
This has nothing to do with magic_quotes. I have applied your
magic_quotes_warning.patch and do not get the warning message that I should if
get_magic_quotes_gpc() was on. I have this in my /etc/php.ini
; Magic quotes for incoming GET/POST/Cookie data.
magic_quotes_gpc = Off
The reason I have makeSafe() "turned on" is that I assume that eventually we
will make it use addslashes() in it and I wanted to find any issues that doing
so would produce in the course of testing.
What I have found is that input fields that use xinha have this issue when
makeSafe() uses addslashes().
Does that help...
PS: I am still not finished testing the select/update/delete patch
--
Tony lambregts
