Re: Re: Why Global Variables turned off??

You can do this with: extract($_REQUEST, EXTR_SKIP) However, you are making some invalid assumptions here. Script variables get initialized after the request variables are automatically imported, so this overwrite switch could not be a high-level php.ini switch. You can do it with a user-space level function like extract() because in this case you can choose when to pull the request variables into your script. I actually prefer doing the opposite. Something like: <? $name = $age = $gender = true; extract($_REQUEST, EXTR_IF_EXISTS); ?> This fetches only the variables I have defined into the global symbol table. -Rasmus On Fri, 3 May 2002, Luis Ferro wrote: > That would be easy to solve by just adding a non_overwrite flag to the > vars and thrus forbid the vars from get/post to override vars in the > varspace that come from programming and not from get/post... > > One would keep the global vars but would also have the security of the > existing/declared vars be protected from overwrite (only get/post vars > would be allowed to be overwriten between page initializations)... > > Cheers, > Luis Ferro > > Matt Parlane wrote: > > >Posting the variables might solve the problem in this case, but remember > >that this is just an example, and I'm sure any creative mind could come up > >with a whole heap of ways you could exploit something like this. > > > >On the other hand though, you don't have to use it. If you are confident > >you can write an application without using the new superglobal arrays (and > >it is conceivably possible), you can just turn register_globals on. It's > >just a choice which was made by the PHP developers (rightly so I believe). > > > >Matt > > > >"Then" <thenovice5@hotmail.com> wrote in message > >news:Xns92037886FF103thenovice5hotmailcom@216.92.131.4... > > > > > >>Hi > >> > >>At the cost of sounding dense...wouldn't POSTing the variables solve the > >>problem. Then the user would not see them in the URL. > >> > >> > >>matt@zevi.net (Matt Parlane) wrote in > >>news:20020503012203.96157.qmail@pb1.pair.com: > >> > >> > >> > >>>Hi... > >>> > >>>The problem comes when you are mixing variables recieved from the HTTP > >>>request, and your own user variables. Consider the following code: > >>> > >>>function authenticate_user(){ > >>> if($password == 'secret'){ > >>> $authenticated = 'yes'; > >>> } > >>> return $authenticated; > >>>} > >>> > >>>If someone passes the variable authenticated=yes in the url request > >>>string, the user will be authenticated no matter whether their password > >>>matches or not. This is obviously a simplified example, and I'd hope > >>>that no programmer would ever do this, but things like have been known > >>>to happen, and there have already been exploits for it. > >>> > >>>The logic behind the change is that it is really not much extra work to > >>>type $_GET['something'] than just $something, and it is infinitely more > >>>secure - so you should write your scripts using the $_REQUEST variables > >>>whenever possible. > >>> > >>>Hope that helps... > >>> > >>>Matt > >>> > >>>"Then" <thenovice5@hotmail.com> wrote in message > > >>>>>>news:Xns92031D273FB9Ethenovice5hotmailcom@216.92.131.4... > >>> > >>> > >>>>Hi All > >>>> > >>>>I am a PHP newbie. I don't understand why global variables are turned > >>>>off > >>>> > >>>> > >>>by > >>> > >>> > >>>>default in PHP4.2.0... something to do with security. Could some one > >>>> > >>>> > >>>please > >>> > >>> > >>>>help me understand how it's a security issue. Thanks > >>>> > >>>> > >>> > >>> > >>> > >> > >>-- > >>Lots of Luck > >>theN > >>thenovice5@yahoo.com > >> > >> > > > > > > > > > > > > > > > -- > PHP Windows Mailing List (http://www.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php >