On Tue, 14 Jan 2003, Rasmus Lerdorf wrote:
> > Check out this bug report:
> > 
> >   http://bugs.php.net/16155
> 
> Ah thanks, that's where I remember the discussion from.  I do disagree 
> with one part:
> 
>    (c) It shouldn't be possible to prevent $_GET, $_POST,
>        $_COOKIE, and $_FILES from being populated.
> 
> Why in the world not?  I explicitly need to be able to prevent $_COOKIE
> from being populated and showing up in $_REQUEST here at Yahoo because we
> have access functions that we want to force people to go through to fetch
> cookie data.
> 
> I think we should just have a completely clean separation of variable 
> ordering priority and superglobal array population.  Before 
> register_globals it made sense to just have one setting for this as you 
> couldn't have one without the other, but today it doesn't make sense 
> anymore.

How about an ini setting for all autoglobals with all being
boolean except request_autoglobal which takes on 'gpc'.  This
will solve your problem but will introduce one possible problem 
(aside from even more directives to keep track of).  It's nice 
to document:

  "$_REQUEST will always contain a mix of..."

Instead of:

  "$_REQUEST may contain a mix of ... depending on your
   request_autoglobal directive."

Sure currently it depends on variables_order but few know the
true power of this directive and even fewer are tempted to
mess with it.  Having the contents being consistent is nice
but is it required?

One last thing.  Some people ask for the ability to hide certain ENV
and SERVER variables.  This is a related topic that might want to
be addressed at this time.  One thought for env:

  0               = Variable won't exist.
  1               = Entire variable will exist.
  "RUNLEVEL,PATH" = Partial variable exists except these.

BUT, this would mean getenv() would need to be brought into
the picture too so this topic will need a new related idea and
may want to be ignored for now :)  It would sorta be like
disable_variables vs disable_functions.

Regards,
Philip



-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to