For all those people who were like me at one time doing the long process of

$thing1 = $_GET;
$thing2 = $_GET; ...

$thing1 = $_REQUEST;
$thing2 = $_REQUEST; ...

$thing1 = $_POST;
$thing2 = $_POST; ...

$thing1 = $row;
$thing2 = $row; ...

etc.
we probably all have done this at some time.

This is the most important code I own that saves u lots of time from doing the above.

foreach($_GET
foreach($_REQUEST
foreach($_POST
foreach($row

what ever you're getting the value with

foreach($_REQUEST as $key => $value)
$$key = $value;

This takes the value and assigns it to the name if your passing the variable named "thing1", thing1 gets assigned.

therefore after the foreach loop you can access your variables like you could before

$thing1, $thing2, $thing3...

This loop replaces all those calls.

Yeah, never do that. It's why register globals are deprecated and soon to be removed from the language. I repeat: DON'T DO THAT

Yeah, never do that. It's why register globals are deprecated and soon to be removed from the language. I repeat: DON'T DO THAT

So what's that mean? What will they use instead?

The correct method, using $_GET, $_POST, $_SESSION, $_COOKIE , etc. You may think it's a clever fix but it is a huge security hole. Clever may be fun but it's usually not the correct solution.

That's debatable.
I use foreach on $_POST/$_GET but i use a white list to prevent injection.
clever works as long as you cover all angles.
Saying, "Clever may be fun but it's usually not the correct solution." is just plain wrong. Usually clever works, sometimes it can backfire.
The foreach method saves time and looks cleaner. If you use this method I suggest using a white list, then comparing in the loop by using in_array. I have used this method for years.

Saying, "Clever may be fun but it's usually not the correct solution." is just plain wrong.

Clever is usually wrong, elegant is usually right. It's when you dont know the difference when things go bad. And if you think clever is the correct answer more often than elegant then I don't want to be anywhere near your code :)

You mentioned using a whitelist, he doesn't. Like I said, there's a reason register_globals is going away.

Well if we want to play word games you could dodge like that.
I would rather have a clever script than an elegant script, mainly because clever shows inventiveness and skill while elegant is just saying the script is pretty, graceful, and smooth. I would prefer a script that shows skill than a pretty script; tho these kinda go hand in hand. After all skill usually is accompanied by good security measures.

I agree, without a whitelist using the foreach method is a huge security hole. When i was a noob i learned that the hard way. register_globals is going away for a reason, thats why I always turn it off.

I just disagree with your statement about clever. Not trying to argue with you but this is just a play on words. You seem to be distraught about my statement.

Well if we want to play word games you could dodge like that.
I would rather have a clever script than an elegant script, mainly because clever shows inventiveness and skill while elegant is just saying the script is pretty, graceful, and smooth. I would prefer a script that shows skill than a pretty script; tho these kinda go hand in hand. After all skill usually is accompanied by good security measures.
...
I just disagree with your statement about clever. Not trying to argue with you but this is just a play on words. You seem to be distraught about my statement.

It's not a play on words. There is a VERY large difference. Elegant can be clever but clever isn't always elegant.

And I don't mean elegant as in style like your braces are in alignment and you have consistant tabs/spaces, etc. That's not what I mean by elegant.

What I mean by elegant is the simplest solution possible to solve the problem that is A) maintainable and B) understandable. As I said, clever can be elegant but it rarely is. Cleverness lends itself to code show-boating. When programming you shouldn't be trying to prove you're the best programmer, you should be solving the problem. If you prefer coding in such a way that shows off your skills then I wouldn't want to be on your team.

Maybe I'm jaded from professional development but there is one quote that has always stuck with me:

"Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." --Brian Kernighan

Well, I am not going to play a word game with you. Using the definitions of these words, I already stated my case.

You can tell me you won't want to be on my team but the offer was never made. You can't admit you may have been wrong, fine. Agree to disagree. You, for some reason, are trying to offend me but it's not possible. I have no idea who you are or how your code is, nor do i care; I won't attempt to belittle your skill as it seems you are attempting to do to me. I have nothing to prove to you, my paycheck says enough for me.

You can pull the professional development card, but I am a professional myself and have been for years. My only problem here is bad information, this has gone on way too far from a simple response on an informative post. A little childish, i'm sure you can agree on that.

You can argue all you want. When you brake it down it's a matter of opinion. You know nothing of me or my code so take you insults with you, they don't work.

OK, I'm not sure where I tried to offend you, if I did I apologize since that was never my goal and I'm not sure why you were reiterating the point about a word game when I already cleared that up. And you can't say that something is a matter of opinion then say the other person is wrong.

I've also said nothing of your skill, I've only made mention of your choice of development principle.

One could say it is a testament to your pride as a developer that you've been a PHP programmer for 9 years and still believe in your development principles which could be considered a good thing.

Perhaps it is my writing classes from college that interfered with my judgment. I was always taught if you want to voice your opinion state it as your opinion, it avoids these exact situations. I was only saying your opinion was wrong because you made it sound like a fact instead of your opinion. Seems to be a big misunderstanding. Sad day when two professionals can't distinguish that. Either way, this topic has gone off subject.

Security is always a touchy subject with programmers, perhaps because i deal with security daily, i do get quick to defend certain ideas. As i stated before, i agree with you. I just didn't agree with your opinion about clever scripts. I use dictionary terminology and obviously misunderstood you reasoning. Either way, I'm the noob on these forums and I'm just trying to help out where i can. Not trying to step on anyone's feet but i do like good debate, where appropriate.

That's debatable.
I use foreach on $_POST/$_GET but i use a white list to prevent injection.
clever works as long as you cover all angles.
Saying, "Clever may be fun but it's usually not the correct solution." is just plain wrong. Usually clever works, sometimes it can backfire.
The foreach method saves time and looks cleaner. If you use this method I suggest using a white list, then comparing in the loop by using in_array. I have used this method for years.

If you're still around, it would be great if you could post the code for the white list method. I've been doing this for a long time and didn't realize is was a problem.

I'm a bit confused about the $_REQUEST variable now after reading this.
Any user input should always be treated as tainted, but as far as I can see, $_REQUEST is just a catch-all "automatic global". As long as the data is cleaned, where is the harm?

I went here:
http://php.net/manual/en/reserved.variables.request.php

It says nothing about about being depreciated. In fact, they have added a new method to define the array order as of 5.3.

Can someone clear this up for me?
Thanks.

I said nothing about _REQUEST being deprecated, I said register_globals is being deprecated. I said it was the reason WHY register_globals was deprecated because

foreach($_REQUEST as $key => $value)
$$key = $value;

is exactly what register_globals did which is a massive security risk. If you clean your variables that's different but in my opinion variable variables ( $$var ) and extract() are bad practices that make code hard to follow anyway.

Edited 6 Years Ago by ShawnCplus: n/a

Can anybody post a safe alternative, or the foreach($_REQUEST as $key => $value) {$$key = $value;} code modified to render it safe?

I've been using this for a long time, not realizing it wasn't safe. It would be great to have a safe version or equivalent.

Here's the safe alternative

$myvar = filter_var($_GET['myvar'], FILTER_VALIDATE_INT, array('options' => array('default' => 15)));

Here's the safe alternative

$myvar = filter_var($_GET['myvar'], FILTER_VALIDATE_INT, array('options' => array('default' => 15)));

Thanks for providing that.

Is that something we'd put inside the foreach noted previously, or would be do that separately for each variable we know we want to use?

no, foreach would go away. The way I usually do it is use a "clean" variable and filter_input_array_array to save time like.,

$clean = filter_input_array(INPUT_GET, array(
  'page' => FILTER_VALIDATE_INT,
  'email' => FILTER_VALIDATE_EMAIL
));

echo 'My page is ' . $clean['page'];

It sounds then like I'd still have to be using concatenation to move in and out of quoted strings in my echo statements, which is what I was trying to avoid when I started using the foreach - I found it made my statements hard to read and debug.

If I understand your code, I'd still have to manually enter each attribute in the array?

What about using your code to sanitize the data, then use a foreach loop to create the variables as before? It there is a concern about malicious attributes being inserted, perhaps the list of attribute names could be used as a whitelist.

My opinion is that the foreach method is insecure, difficult to follow and overall bad practice. I don't believe it should ever be used A) because a method exists to do that already ie., extract($_REQUEST); is the same as foreach($_REQUEST as $key => $val) $$key = $val; B) it makes it hard to search for the initialization of a variable.

With the filter_input method it is easy to see where the variable comes from, what type it is (email, string, int, etc.), it has built in validation and sanitization based on what filter you used.

As for "I'd still have to manually enter each attribute in the array?" yes, yes you will. That's the point is that you should KNOW exactly which variables are coming in from GET. If you're trying to do it automatically because there are a lot of them or you don't know what it will be then there is something wrong with your application design.

As far as concatenation goes, I prefer that style, I find it cleaner and if you use an editor/IDE with any form of decent syntax highlighting it is much easier to read/debug (though more verbose than keeping it in the string). Some people will say something about performance but it's negligible either way so don't believe that one. It all boils down to preference, if you really don't want to concatenate you can still do echo "I have a string with $somearray[key]";

Comments
Well considered, constructive input.

Thanks Shawn, that's all good food for thought.

I'll have to sit down and really look at extract() and filter_input_array().

Always something new to learn!

This article has been dead for over six months. Start a new discussion instead.