Zeev Suraski schrieb:
- My mind is pretty firm about implementing shortcuts for
$HTTP_*_VARS. People are going to rebel big time if we remove their global
variables by default, and make them use these exceptionally long
alternatives instead. Most people I talked to (virtually all of them
except for you :) agreed with that
- E_SECURITY is a good idea, but like the other ideas raised in this
discussion, it doesn't have all that much to do with the specific issue at
hand. We have no magical way of detecting usage of variables which is a
potential security risk, as opposed to one which is not. Unfortunately,
both are very common.At 05:45 28/07/2001, Hartmut Holzgraefe wrote:
>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]--
Zeev Suraski <[EMAIL PROTECTED]>
CTO & co-founder, Zend Technologies Ltd. http://www.zend.com/--
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]
