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 tony.lambregts@gmail.com 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