[geeklog-devel] Re: [geeklog-devtalk] Variable best practices

[Tony Bibbs]

Knowing that there have been security issues with anything prior to 4.2 
(and, indeed, after), I don't think it is a stretch to have Geeklog 
require 4.1 or better.  In fact, we should probably have a rule that 
Geeklog will support so many revisions behind the most current.  I mean, 
seriously, should we be concerned with people who are still using 
pre-4.1 (hell, the 5.0 launch isn't all that far away)?  I think 
not....simply because I can't fatham that many people out there with 
that old of a version.  Sure, that means you have some inconsistent code 
(i.e. some that can handle no register_globals and some that can) but to 
me that at least introduces the ability to start making the switch and, 
at the very least, encourages good coding habits.

As you can tell, I have an opinion.  I say ditch pre-4.1 support and 
let's start using $_REQUEST, $_GET, $_POST and be happy.  I, of course, 
could be swayed if there is enough uproar to convince me pre-4.1 support 
is needed.

Thoughts?

--Tony

Blaine Lang wrote:
> Maybe, I can only receive emails on this list ;)
>  
> Another suggestion where this function would be helpfull is in say .....
>  admin/topic.php -- I believe $tid and $topic are variables that are 
> passed as GET or POST vars.
>  
> You need to check for both, post is higher in presidence and if not set 
> it to '';
>  
> Just a thought -- I'll stop sharing now.
> 
>     ----- Original Message -----
>     *From:* Blaine Lang <mailto:geeklog at langfamily.ca>
>     *To:* geeklog-devtalk at lists.geeklog.net
>     <mailto:geeklog-devtalk at lists.geeklog.net>
>     *Sent:* Sunday, February 29, 2004 1:19 PM
>     *Subject:* Re: [geeklog-devtalk] Variable best practices
> 
>     I've been wanting to address this issue for a while and have come up
>     with the following function.
>      
>     It will filter either GET, POST or both (as in my need noted below -
>     but look for POST first).
>     It will appy the data filter - default mode for now.
>     It will also optionally create GLOBALS out of the variables. This
>     could be used to remove a dependany on Register_globals.
>      
>     Example use:
>      
>     $myvars = array('op','profileid','memberid');
>     getdata($myvars,true);
>      
>     or
>      
>     $formvars = array('profile_name','member_num', 'member_addr',
>     'member_city', 'member_phone');
>     $formdata = array();
>     $formdata = getdata($formvars,'POST');
>      
>     << code begin >>
>      
>     function getdata($vars,$setglobal=false,$type='')  {
>       $return_data = array();
>      
>       #setup common reference to SuperGlobals depending which array is
>     needed
>       if ($type == "GET" OR $type == "POST") {
>         if ($type=="GET") { $SG_Array=& $_GET; }
>         if ($type=="POST") { $SG_Array=& $_POST; }
>      
>         # loop through SuperGlobal data array and grab out data for
>     allowed fields if found
>         foreach($vars as $key)  {
>           if (array_key_exists($key,$SG_Array)) {
>     $return_data[$key]=$SG_Array[$key]; }
>         }
>      
>       } else {
>         foreach ($vars as $key) {
>           if (array_key_exists($key, $_POST)) {
>             $return_data[$key] = $_POST[$key];
>           } elseif (array_key_exists($key, $_GET)) {
>             $return_data[$key] = $_GET[$key];
>           }
>         }
>       }
>      
>         # loop through $vars array and apply the filter
>         foreach($vars as $value)  {
>           $return_data[$value]  = COM_applyFilter($return_data[$value]);
>         }
>      
>       // Optionally set $GLOBALS or return the array
>       if ($setglobal) {
>           # loop through final data and define all the variables using
>     the $GLOBALS array
>           foreach ($return_data as $key=>$value)  {
>             $GLOBALS[$key]=$value;
>           }
>       } else {
>           return $return_data;
>       }
>      
>     }
>      
>      
> 
>         ----- Original Message -----
>         *From:* Blaine Lang <mailto:geeklog at langfamily.ca>
>         *To:* geeklog-devtalk at lists.geeklog.net
>         <mailto:geeklog-devtalk at lists.geeklog.net>
>         *Sent:* Sunday, February 29, 2004 10:19 AM
>         *Subject:* [geeklog-devtalk] Variable best practices
> 
>         As a practce, I try not to have any register_globals
>         dependancies. I will use the full $HTTP_POST_VARS
>         and $HTTP_GET_VARS variable names. I'd lole to use the other
>         supper globals ($_REQUEST, $_POST and $_GET) and are still
>         dependant on php version 4.1 or greater. Most hosting services
>         should be running by now but it can not be assumed I guess.
>          
>         I'm filtering all expected POST and GET vars now in my new
>         plugins and there are still times it makes sense to use the same
>         name in the POST and GET. It may be passed in the URL or form so
>         you have to check both but I check the post first as I would use
>         that first if I can post a hidden variable.
>          
>         Examples are:
>         using $op to indicate operation. I may be triggered from a link,
>         selectbox, image or button in the UI. I may also have to pass it
>         to another script.
>         using $page and $sort as part of the page google like navigation
>         (links) but you also need to retain this as hidden fields in
>         forms if you want to retain your page position.
>          
>         I don't see the reason to use different names with the get and
>         post as this allows me more control. I only expect it one way or
>         the other and POST should override get.
>          
>         Hense why I end of having all this extra code at the top of scripts:
>          > if (isset($HTTP_POST_VARS['op']) ) {
>          >     $op = clubApplyFilter($HTTP_POST_VARS['op']);
>          > } elseif (isset($HTTP_GET_VARS['op']) ) {
>          >     $op = clubApplyFilter($HTTP_GET_VARS['op']);
>          > } else {
>          >     $op = '';
>          > }
>          
>         Is this how others would approach this?
>          
>         I was thinking if I am having to repeat this practice and common
>         code, others would as well. Extending my class object to handle
>         this would be an advantage.
>         $myfilter = new COM_filter;
>         $myfilter->_censor = true;
>         $myfilter ->_jsfilter = true;
>         $op = $myfilter->_setvar('op', 'text');
>          
>         Cheers,
>         Blaine
>          
>