Re: notice and warning

Dale schreef:
"Erwin Moller" <Since_humans_read_this_I_am_spammed_too_much@xxxxxxxxxxxxxxxx> wrote in message news:4885dbe8$0$49958$e4fe514c@xxxxxxxxxxxxxxxxx
Barry schreef:
"Erwin Moller" <Since_humans_read_this_I_am_spammed_too_much@xxxxxxxxxxxxxxxx> wrote in message news:487e1e6b$0$14347$e4fe514c@xxxxxxxxxxxxxxxxx
Jeff schreef:
<snip>

Don't use $_REQUEST[].
Use $_POST or $_GET or $_COOKIE or whatever you need, but don't use $_REQUEST.
Doing so means you don't know where your data comes from.
(Some people, like me, think it should never have been added to the language.)
Hi Barry,

Sorry for late response: I have been working way too much hours elsewhere the last few days. Back now. :-)


what's wrong with $_REQUEST, erwin? i use it as standard practice. i have the order set in the php.ini to my liking - it happens to be the default. if i need to get fussy where my data is coming from, then i specifically use the one i need, i.e. $_POST/GET/COOKIE et. al.. using $_REQUEST scales better also since you may change your implementation on how the script is being called/used. being specific when not needed means you'll have to re-write that portion of the script...not so with $_REQUEST.

just wondering what your reasoning is.

An example:
You expect some piece of data from a post in your script, eg: userid.
So you use $_REQUEST["userid"] which works perfectly fine as long as you get the userid in via POST.
Let's say this script deletes user the user: userdelete.php
So we have userdelete.php that expects a userid from POST.

Now suppose you leave your fine-running app for a year or so, untill your client wants some upgrades to it.
In some unrelated part of your app you decide to store a userid in the $_SESSION so you have it easy at hand on some other pages. The userid contains the userid of the currently logged in user.

Now you find yourself in the situation that when you call this script for any reason without the POST info, you will delete yourself if you prefer $_REQUEST over $_POST.

Same can happen with get of course.


Hi Dale,

Are you the same as Barry by the way?


as well as cookie. i don't see the point. how you get the input in this scenario is not going to be problematic to the script...not programming for the scenario itself is.

I thought I just pointed out how it can be problematic.
With a simple example (the userdelete-script) that shows how you needlessly complicate things if using $_REQUEST.


further, i may want to reuse userdelete.php in
another script...users.php. you are forcing users.php to inherit userdelete.php's implemenations. that's bad design.

I have no clue what you are saying here.
How on Earth are you going to reuse code in another script without checking if it fits in???

My example is not 'inheriting' anything. It was just ment as an example for ONE script, not some class you implement everywhere...
If you copy/paste code from one script to the next script without understanding 100% what you are doing, you are bound for serious trouble.

And what 'bad design'?
Are you claiming using $_REQUEST instead of $_POST/$_GET/whatever, is BETTER design? You can't be serious.


as for willy-nilly deleting a user,

willy-nilly?
I have honestly no clue what that means, since I am not a native english speaker. Sorry. :-)

a confirmation that the end-user really
wants to delete user x helps avoid that.

Of course it avoids that.
I was just giving you a possible scenario where using $_REQUEST leads to trouble.
So let's say for the sake of the discussion that in my example the scripts posted to is the script AFTER the confirmation, ok?

Let's please not dive into such silly arguments as when to show a warning and when not. That is beside the point I think.


however, the catch all is not
REUSING the ID in the first place. that's just asking for trouble.

If you are in the habbit of using $_REQUEST it is indeed asking for trouble....
If you use the right superglobals, you'll NEVER think about that 'problem' again.


again, i think a better example is needed...though i do appreciate this one.

Here is one:
You receive a phonecall:
A friendly female voice says:
"Hi Barry/Dale, this is a collect call from... "
Barry/Dale interrupt: "I don't care where it comes from, I'll take it anyway."

Well, that is just a silly joke, but I am firmly convinced you should take your data where it is supposed to come from, so never use $_REQUEST.
Besides that: Using $_REQUEST simply doesn't offer any advantage at all, only slightly shorter code in some cases.

Do you use:
SELECT * FROM ....
instead of naming the columns too?



Of course, all this can be avoided easily if your program perfectly and never make mistakes, but I doubt that. ;-)

there are mistakes like using $someVar in one place and $someVare in another - a type-o. a script that has not been tested for the most basic of things, as in this example, is no mistake. it is poor workmanship. i can guarantee that *every* time i program something, there will *never* be poor workmanship in it even though it will have had, at some point, mistakes in it.

don't doubt that.


I do not want to insult you: But since you prefer using $_REQUEST over the appropriate superglobals, I do doubt your workmanship.
Of course, you can always change my mind by giving a valid reason why you do so. I don't think there is one.


So, in my opinion, it is always better to state where you get your data from.

i haven't found that to be my case. i do use post/get/cookie specifically, but only when it is absolutely needed...like obfuscating security, i.e. processing a request that should have both get and post data, not just one or the other.

I am glad you found a reason to use it, but honestly that reason doesn't make a lot of sense to me.
Sorry mate. :-/
If that is security for you, you'll have still a long way to go.

Using $_GET or $_POST or $_REQUEST has absolutely nothing to do with security.
They only have to do good clean programming, which is of course the first step to secure applications.



If we stick to your example: You say using $_REQUEST scales better.
I say it bugs better. ;-)

no, the mistake is in allowing your system to *reuse* user id's...not how it came about that someone is just saying to delete said id.

Mistake?
Let me restate that, it is getting more and more amusing.

Do you claim that: "Since it is better to use $_REQUEST over $_POST/$_GET/etc, you should also NEVER use the same variable (or better: key in associative array) in your posts/session/get/cookie."

Is THAT what you say?


post doesn't know
that the user is doing something they ought not do, neither does get, nor cookie.

Indeed. They are merely superglobals, one shouldn't expect them to know anything except what they are build for: holding the information they are suposed to hold. Using them wisely is up to the programmer that implements them.


if that's how you validate user interaction with your system, i hope
you're a good magician.

???
I wonder how you communicate with user if you don't use their info.
Post/Get/Cookie are the only communication you have with a webclient....

And no, I am not Richard Stallman, I am no magician, that is why I program defensive.
I hold that as a good habit.

you'll find another co-worker, oblivious to your
post/get/cookie 'rule' and he'll kill your how dataset of users inadvertently.

What? My 'rule'?

And something tells me you haven't worked too often with other PHP programmers, otherwise you surely would avoid $_REQUEST.


this is why we develop *architecture* that clearly defines
the condition(s) in which things can be done.

Good for you.
But this sounds as empty to me as: "That is why we try to develop software without bugs."
It is an open door, and has nothing to do with the topic at hand.

Coreproblem is simply this: You are receiving your data from unknown sources instead of pinpointing where your data comes from.
That is inferior programming compared to being more specific.
Period.

What architecture you use has little to do with my above statement.
I mean, if a script allows to delete a user (passed by userid) is up to the script, and the problem at hand.
That is valid for both our positions! (your $_REQUEST or my specific superglobal.)


it keeps users from doing
things they shouldn't and developers aware of the rules in place so they too don't do something they shouldn't...at least if they do, you can easily pin-point where things went wrong. :)

Yes, using $_REQUEST in favor of the appropriate superglobal will surely keep you busy with pinpointing problems.
You haven't given me ANY reason to use $_REQUEST yet.

I think we work widely different...

Regards,
Erwin Moller

PS: Please try to use CAPITALS at the beginning of your sentences. Makes it so much easier to read for me. :-)


.

Relevant Pages

  • Re: notice and warning
    ... You expect some piece of data from a post in your script, ... So you use $_REQUEST["userid"] which works perfectly fine as long as you get the userid in via POST. ... Now you find yourself in the situation that when you call this script for any reason without the POST info, you will delete yourself if you prefer $_REQUEST over $_POST. ... Saying that using $_REQUEST 'scales better' is utter nonsense. ...
    (comp.lang.php)
  • Re: notice and warning
    ... You expect some piece of data from a post in your script, eg: userid. ... prefer $_REQUEST over $_POST. ... in this instance, it scales more 'easily'. ...
    (comp.lang.php)
  • Re: GoTo in Java
    ... smaller, decomposed, functionality. ... maintaining script, ... > It used a component programming model and provided a visual development ... > package graphs as macros for use in other graphs. ...
    (comp.lang.cobol)
  • Re: notice and warning
    ... You expect some piece of data from a post in your script, ... prefer $_REQUEST over $_POST. ... the different meanings the input should have based on how it arrives. ... that's bad design. ...
    (comp.lang.php)
  • Re: Problem with a script
    ... I don't mean to offend you or discourage you from working with PHP, ... Reworking your huge script into something concise, ... that I have no understanding of loops is completely asinine. ... throw that in while I am on the subject of programming. ...
    (comp.lang.php)