Zeev Suraski wrote:
> Anyway, to be more constructive - Andi had an idea when we were catching a
> cab earlier today (yesterday). His idea (which I'm just pitching, we
> haven't thought this through at all yet) is that instead of having
> register_globals on, or off, we would have it as unset, by default. When
> unset (i.e., on new installations) - PHP will not run, but instead display
> information about register_globals, its security implications, examples,
> and a general recommendation to turn it off if at all possible. We can
> easily point the user to the location of the php.ini file that he has to
> edit in order to modify register_globals to be either on or off.
i was thinking about having an additional error_level E_SECURITY besides
E_NOTICE and having both of them activated by default in future php.ini
distributions
although i like your idea too, i'm afraid it won't reach all users as
often they are not the ones who do the installation but just use it
so chances are that the system administrator responsible for installing
php just turns register_global off again after installation while the
warnings produced will never reach the developers
E_SECURITY, on the other hand, would have effect at runtime, not on
installation, and the message would reach the developers (if they
care at all, i have seen enough code having @s in all places or
beginning with error_reporting(0) :( )
besides that E_SECURITY could be used in other places as well ...
the only drawback on my solution right now is that E_SECURITY together
with display_errors would breack every script generating HTTP headers,
as globals registration is done way before the script is started
so i thought of an additional mechanism that would not register GPCs
generally as globals but on demand, producing warnings whenever the
feature is really used instead of when it is generaly turned on
like <?php echo $a[hello]; ?> produces
Warning: Use of undefined constant hello - assumed 'hello' ...
or <?php echo $hello; ?> leads to
Warning: Undefined variable: hello
we could register globals on demand while issueing
Warning: Undefined variable: hello - assumed $HTTP_GET_VARS['hello']
ok, this might lead to a slight performance hit with register_globals
on,
but i wouldn't as it is identified as bad practice anyway as long as it
doesn't break existing code but just slows it down
> [...] it'd encourage (force) application
> developers to write portable applications (which is a good thing - apps
> based on register_globals=on are not portable, [...]
hm, maybe having E_PROTABILITY as an additional error_reporting level
would be worth a thought ... ?
PS: i definetly like the idea of having track_vars generate a FORM array
of some sort containint both GET and POST vars, being able to change
from methods without having to double-check the form processing code
could be worth it
regarding the convenience of having _GET[] besides HTTP_GET_VARS[]
and such i'm not sure yet (and i hope i got it right that both
variants will be just references to the same array internally ?)
maybe having another ini-parameter like short_track_vars or
convenience_track_vars? as i said, i'm not at all sure about it yet
...
--
Hartmut Holzgraefe [EMAIL PROTECTED] http://www.six.de +49-711-99091-77
--
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
