On Feb 13, 2008 11:46 AM, <[EMAIL PROTECTED]> wrote: > Quoting Jesse Becker <[EMAIL PROTECTED]>:
> You said the only patching would be to include this script in > get_context.php and graph.php. So, I take that to mean that > get_context.php and graph.php would still access values in $_GET like > they currently do, but these would be modified by santize.php. Yes and no. This file will be included by anything that is "front-facing". So index.php and graph.php like I mentioned, but also the host_view, cluster_view, etc files. Not a big deal though. Right now, the idea is to *NOT* change any data, just accept or reject based on some basic type checking. $_GET (et al) remain available to the other scripts (index.php, et al), but non-validated data is removed. Essentially, something exists in $_GET if, and only if, it has explicitly been declared "okay." > I think it'd be clearer to do everything in one place. Then, the only > script that touches $_GET/$_COOKIE is sanitize.php, and all other > scripts use variables that it makes available. That way you have only > 1 place where user input is touched, and $_GET continues to be what > you'd expect: raw user input. Exactly. Now, if we decide to do any sort of "cleanup", that could be either a separate stage (maybe "clean.php"), or left to the relevant sections of the other code. > In the foreach() loop, if a $_GET value is found to be valid (the if() > condition is true), put the value in a $clean array, using the same > key as $_GET/$_COOKIE. All other code should use these values from > the $clean array rather than the current local variables. When > reading other scripts, this convention makes it clear that a variable > is user input, and that it has been put through appropriate checks. That's a thought, and not difficult to do. It would mean changing all other code that currently uses $_GET to use $clean. Not a big deal--just a big search and replace. (Options like this are why I'm asking for input--I thought of doing it both ways, but wasn't sure which would be preferred in this case.) > If a value is invalid, maybe create the key in $clean with a sane > default value, or a null if no sensible default is possible. Code > that wanted to use something in $clean then wouldn't need to do lots > of isset() checking. This is pretty much what get_context.php and > graph.php already do. Default values are an issue. The should be handled in a different step though. This could be part of a "clean" stage, to ensure that everything that needs to be set is, in fact, set. > Won't the INT, FLOAT, and NUMBER checks in valid_parameter() always be > true? (float)$value would always be a float. Hmm...true. I was thinking of the case where where you have something like: $float_var="cow"; is_float($float_var); What is the floating point representation of a bovine? I'll need to go back and check on type casting. I was trying to avoid using regexes for generic validation tests, but looks like that might be the way to go. > The BOOL check is allowing a 1 or 0, not an actual boolean. If I saw > a value being validated as BOOL, I'd expect it to be a boolean, not a > 1 or a 0. Mostly it doesn't matter since PHP is so loose with types, > but the broken 'Show Hosts' bug in 3.0.6 shows that the difference > does matter in some cases. This is an issue with the is_bool() PHP function. It actually wants a true boolean value of True of False, not a string that is "0" or "1". Most/All of this data in $_GET is ultimately handled as string values. For things like the "show hosts" flag, we aren't given real boolean values; we are given a string. More regex fodder... > error_log calls should identify where they are coming from. > Alternately, you could trigger_error( "message", E_USER_WARNING ). > That automatically adds information about file and line number where > the error occurred. Noted. Will add. > Hope that's helpful, Very much so. Thanks. -- Jesse Becker GPG Fingerprint -- BD00 7AA4 4483 AFCC 82D0 2720 0083 0931 9A2B 06A2 ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Ganglia-developers mailing list Ganglia-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-developers
