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) {
foreach(Array(
'_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.
unset($transvar);
}
> 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
[EMAIL PROTECTED]
www.PHPBeginner.com // where PHP Begins
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
