Matthias Esken <mu************ ******@usenetve rwaltung.org> wrote in message
Your code will work, if register_global s is activated. By default it is
deactivated and activating it might lead to severe security leaks.
See http://www.php.net/manual/en/securit...terglobals.php for
details.
Have a look at the PHP Superglobals in the documentation at
http://www.php.net/manual/en/languag...predefined.php to see
how it should be done.
To Matthias and Pedro. I really appreciate your quick reply, but I was
shocked to see this answer from the contributors of PHP that you so
kindly relayed to me. This is certainly distressing, don't you think?
I mean, now we have to use this convoluted method with the _ vars to
get stuff, particularly _POST. Usually from what I have read about C,
when something begins with _, it's usually meant that you weren't
supposed to call it.
Here's my spin. Perhaps the PHP team found out about the security
problem, and this put PHP in a dangerous situation, so they decided to
use the fallback with the underscore var technique as an emergency.
Do you see how countless developers will begin writing stuff for this
rev. of PHP, using the _POST technique, and it certainly could be
deprecated in the near future, putting all those projects at risk of a
rewrite?
My commentary to the PHP team is to remedy the situation rapidly. It's
not a big thing that they should do. I believe they should write
another routine that abstracts the _POST routine with a non-underscore
var, such as, dare I say, 'Request("usern ame")', and that way they can
change the underscore vars on a whim without breaking anyone's code.
Either that, or permit PHP developers to use C-like macros so that we
can rename _POST with Request.
But, saying this, please understand I'm a newbie to PHP. My skills are
in C, VB, ASP, JSP and have recently been impressed with some of the
features of PHP. My commentary is not a seasoned one and I welcome
your opinions to educate me on why things are the way they are.
