On Fri, 4 Oct 2002 20:50:32 +1000
Adam Royle <[EMAIL PROTECTED]> wrote:

> Hi All,
> I have been a subscriber of php-db for quite some time, and I have seen 
> MANY ppl ask why their variables aren't being passed though, etc, due 
> to register_globals, etc, blah blah blah
> I have kept my eyes open reading all the material I can, and I 
> understand the security implications of certain programming actions.
> Like most programmers, I am lazy. I prefer to construct functions to do 
> the hard work for me. Before the register_globals issue was widespread, 
> I loved programming in PHP (compared to ASP), because of the automatic 
> passing of variables from page to page (also, referencing undefined 
> variables without a hitch).I had some techniques to deal with security, 
> and other things, so register_globals = on wasn't such big deal for me. 
> But I acknowledge that if I do contract work for a business, and their 
> server is set to

Not only that it is better security-wise, but also it helps you
differentiate between SERVER, GET, POST, COOKIES and SESSION variables.
Say, you need to always read a session variable called 'id', then, you
install some app that passes 'id' in GET. Isn't it better own the entire
control on the things?

> I have set my php.ini to E_ALL and register_globals = off, etc, 
> although I don't want to have to do $var = $_GET['var'] for each 
> variable i want imported. I have also noted people are using 
> $HTTP_GET_VARS['var'] to allow for older php compatibility. But doing 
> it this way reminds me too much of ASP.

Who cares of ASP? I don't.

> Now, my question is, has anyone created functions or developed 
> techniques to prevent obvious security breaches and also not collapse 
> when using E_ALL? I have read somewhere that some people wrote a 
> function which would accept an array of variable names (and 
> get,post,session flag etc), and globalize all of those variables listed.
> Such an example (i imagine) would be something like this:
> import_vars( "GET", array('id','var2','name') );

I made one. Here:

        // Alter variables for the versions prior to 4.1.0
        // NOTE: $_REQUEST global variable is NOT supported.
        if(strnatcasecmp('4.1.0', PHP_VERSION)>=0) {
                         '_GET'      => 'HTTP_GET_VARS'
                        ,'_POST'     => 'HTTP_POST_VARS'
                        ,'_COOKIE'   => 'HTTP_COOKIE_VARS'
                        ,'_SESSION'  => 'HTTP_SESSION_VARS'
                        ,'_SERVER'   => 'HTTP_SERVER_VARS'
                        ,'_ENV'      => 'HTTP_ENV_VARS'
                        ,'_FILES'    => 'HTTP_POST_FILES'
                        ) as $transvar['new']=>$transvar['old']) {
                        if(isset($$transvar['old']) and is_array($$transvar['old'])) {
                                $GLOBALS[$transvar['new']] = &$$transvar['old'];
                // Unset transvar, we do not need it anymore.

> Now I don't think that I would have any troubles writing this sort of a 
> function, although I was wondering if anyone had already considered 
> this approach, or decided on a better solution. Really, I don't want to 
> have to do isset(), etc on all my vars when using them. What I could 
> deal with is having one line, where I list all the variables i use on 
> the page, and it either imports it or creates an empty string if not 
> found (therefore initializing it).
> What do you all think of this approach?

Well, if you really care then maybe the approach should be:

if PHP version is less than v4.1.0 then start up a file with the code
that gets the HTTP_*_VARS and changes them into $_GET, $_POST etc... 
this makes you being more compatible

> PS. Sorry if this is talked about WAY too much on these lists, but I 
> think this is a more informative thread for people who know about 
> register_globals etc, but want scripting to be easier (and faster) with 
> PHP, but still maintaining a good code structure (and sensible 
> programming logic).

One thing to add:

ever asked yourself why people, after retrieving some data from DB call
their variables similar like: $recID and not just $id or $dbTime and not
just $time? Obviously to differentiate between the origins of data. Now,
if you understood what I meant here, why using $id within the script
instead of $_GET['id'] or $_SESSION['id'] ? Isn't is a cleaner, rather
elegant code? That is a good practice. You shouldn't be lazy writing 6
more characters for a variable... You'd do that anyway for the data
names because would be confused :)

Maxim Maletsky

www.PHPBeginner.com  // where PHP Begins

PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to