From: Julian F. <ju...@be...> - 2002-08-22 08:01:51
|
I was playing around this evening with some functions to pull the variables out of the POST and GET data. This is what I came up with, which seem to work pretty well. get_var() first checks $_POST and then $_GET looking for the variable. The check for magic_quotes simulates turning magic quotes off even if they're on in the system. I've been playing a lot with the string escaping functions and the simplest solution is to make sure strings aren't escaped until they are inserted into the DB. Otherwise string comparisons, etc don't work right. If the variable isn't found, the default is used. If there's no default a user error is thrown... we could use Jeroen's idea of having a $g_mantis_last_error variable to pass in more details to the error handler. The other three functions just call get_var() and then convert the result appropriately to the right type. The advantages of this code as I see it: * we can turn off register_globals and not rely on it being turned on * every page then needs to use these functions to get its variables so: + every variable is documented at the top of the page + every variable has a default, or if none applies, an error is thrown early and is easy to track down + every variable contains valid data of the right type for the rest of the page * additional cleaning, security checks, etc can be easily added globally * as Ken says, hooks could be more easily added in the future * we know that none of the variables have slashes in them so we don't have to worry about double escaping them... this has been biting me all over the place as I clean up code None of this is intended to be changed until we undergo our 0.18 cleanup, I'm not proposing to jump in and change all the code tomorrow. I've also been playing with escaping but I'll post another message on that topic. (code follows) Julian function get_var( $p_var_name, $p_default=nil ) { if ( isset( $_POST[$p_var_name] ) ) { $t_result = $_POST[$p_var_name]; } else if ( isset( $_GET[$p_var_name] ) ) { $t_result = $_GET[$p_var_name]; } if ( isset( $t_result ) ) { if (get_magic_quotes_gpc() == 1) { $t_result = stripslashes( $t_result ); } } else if ( nil != $p_default) { $t_result = $p_default; } else { trigger_error ("Variable '$p_var_name' with no default is missing", E_USER_ERROR); } return $t_result; } function get_var_string( $p_var_name, $p_default=nil ) { return get_var( $p_var_name, $p_default ); } function get_var_int( $p_var_name, $p_default=nil ) { return (integer)(get_var( $p_var_name, $p_default )); } function get_var_bool( $p_var_name, $p_default=nil ) { $t_result = get_var( $p_var_name, $p_default ); if ( 0 == strcasecmp( 'off', $t_result ) || 0 == strcasecmp( 'no', $t_result ) || 0 == strcasecmp( 'false', $t_result ) || 0 == strcasecmp( '0', $t_result ) ) { return false; } else { return true; } } -- ju...@be... Beta4 Productions (http://www.beta4.com) |
From: Jeroen L. <jl...@ca...> - 2002-08-22 09:40:01
|
At 01:03 22-8-2002 -0700, you wrote: >The advantages of this code as I see it: >* we can turn off register_globals and not rely on it being turned on We already had that. >* every page then needs to use these functions to get its variables so: > + every variable is documented at the top of the page > + every variable has a default, or if none applies, an error is > thrown early and is easy to track down > + every variable contains valid data of the right type for the > rest of the page Sounds good. >* additional cleaning, security checks, etc can be easily added globally >* as Ken says, hooks could be more easily added in the future id. >* we know that none of the variables have slashes in them so we don't > have to worry about double escaping them... this has been biting me > all over the place as I clean up code So your proposed functions don't do any addslashing? Oh, wait. You posted code. Looks good. Jeroen |
From: Julian F. <ju...@be...> - 2002-08-22 09:46:29
|
Jeroen Latour wrote: > At 01:03 22-8-2002 -0700, you wrote: > >> The advantages of this code as I see it: >> * we can turn off register_globals and not rely on it being turned on > > > We already had that. [...] Ah, you're right. Well we can turn it off and not worry about people slipping values in for variables we don't expect, then :) Julian -- ju...@be... Beta4 Productions (http://www.beta4.com) |