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

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
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]

Reply via email to