UNSUBSCRIBE ME PLEASE!!!!!!!!!!!!!!
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 hartmut@six.de http://www.six.de
> >+49-711-99091-77
> >
> >--
> >PHP Development Mailing List <http://www.php.net/>
> >To unsubscribe, e-mail: php-dev-unsubscribe@lists.php.net
> >For additional commands, e-mail: php-dev-help@lists.php.net
> >To contact the list administrators, e-mail: php-list-admin@lists.php.net
>
> --
> Zeev Suraski <zeev@zend.com>
> CTO & co-founder, Zend Technologies Ltd. http://www.zend.com/
>
> --
> PHP Development Mailing List <http://www.php.net/>
> To unsubscribe, e-mail: php-dev-unsubscribe@lists.php.net
> For additional commands, e-mail: php-dev-help@lists.php.net
> To contact the list administrators, e-mail: php-list-admin@lists.php.net