Re: notice and warning


"Erwin Moller"
<Since_humans_read_this_I_am_spammed_too_much@xxxxxxxxxxxxxxxx> wrote in
message news:488760ea$0$49891$e4fe514c@xxxxxxxxxxxxxxxxx
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?

yes...i'm playing with jerry stuckle. he likes to plonk people who disagree
with him. i'm trying to fill up his filter(s). :)

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.

like i said in the other post, it's just not at all a strong case to me. i
rely on objects that verify and validate things and the branching actions
that should follow. how the input arrives, in my system anyway, has
*nothing* to do with those particulars...just that i have input to work
with. it's decoupling of the interface.

With a simple example (the userdelete-script) that shows how you
needlessly complicate things if using $_REQUEST.

i also said how needlessly easy it is for another user to overlap
superglobals and *** up your db's data - because you rely on how the input
arrives, not by enforcing rules in the business logic that governs your
site. whether i use request/post/get/cookie, none of your example prevents
disaster...it is merely a hope that all developers know your *hash key* and
the different meanings the input should have based on how it arrives. that's
just a new case of 'magic numbering', just with input venues. it's not good
design.


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???

require_once, include_once, f_open, file_get_contents, etc.. there are a
number of ways to incorporate the reuse of code bases.


My example is not 'inheriting' anything.

one of my points was about scaling. the one script may best have it's
functionality included somewhere else. for your sake, say you have a script
called users.php. that script lists, edits, deletes users. it may 'get' an
input to delete something, at which point, it would want to include_once
deleteuser.php. since deleteuser.php expects a 'post' for the id of the user
to delete, the action won't be performed - no deletion. if i have
edituser.php that expects 'get' inputs, it would be able to successfully
edit a user.

if i want to reuse deleteuser.php, i either have to make it accept 'get'
inputs and thereby change my previously 'magic' business rules, or, i'd have
to change users.php to either now expect 'post' instead of 'get', or force
it to copy the 'get' vars to 'post' vars so that all three scripts would
work (users.php, edituser.php, deleteuser.php).

instead, i use REQUEST for nearly every script i write. i rely on
specifically programmed logic in the form of oop'd class objects to enforce
user input conformance and ensure they, nor other developers in my system,
*** anything up.

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.

no one said anything about that. reusing code is !== copy/paste!

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

i'm saying that *how* your input arrives is irrelevant to how your system
operates. relying on data coming from one venue (POST) to mean something
completely different from another (GET) is an exercise in bad design.

my claim is that BETTER design is removing the importance or related meaning
to the venue(s) from which we expect input.

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. :-)

sorry. it means to choose something based on nothing - haphazardly.

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.

right, i just don't think there's a good way for you to make a good case
using the example you gave. perhaps a different one?

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.

uhm, no, it's not silly - it's relevant.

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

again, that is what i initially countered with AND, it removes the need to
magically rely on, and assume different meanings for, different input venues
(post/get/cookie).

yes, it is asking for trouble.

If you are in the habbit of using $_REQUEST it is indeed asking for
trouble....

no. as you just said, the 'catch all' is not 'reusing' hash keys. all else
is just as prone to the same downfalls mentioned in your example. how does
one prevent key overlap/reuse? i have pointed to oop'd business logic to
drive your system rather than input-magic.

If you use the right superglobals, you'll NEVER think about that 'problem'
again.

if i specify the 'right superglobals' as having some kind of association to
business logic/decisions/actions, i have created failure and invited
mistakes. you cannot enforce your system's design with input venues! you
simply can't! either a user is going to hose you up, or a developer is going
to bite you in the ass. that, and you can't scale easily with that
architecture.

if i don't allow the reuse of hash keys, i can scale. i can also enforce my
business rules (et. al.) and keep both the user and the developers from
fucking my system over. and finally, we aren't working with magical meanings
of data based on where it came from - we have a document system of behaviors
instead.


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."

i may do that in real life anyway. i have free global phone service. but,
this IS a perfect example. you assume that your solution fits EVERY system
in the world. in my 'phone' system, i want to take calls, wtf does it matter
to me where it's coming from? your 'phone' system may cost an arm and a leg.
you may interupt and say "i don't care where it comes from, i refuse the
connection". you also may have several places where the phone call could
have come from - dude, you've only got 3 php input
venues...get/post/cookie - this set could mean that you require more
meanings your phone than what get/post/cookie can magically afford.

oop'd design handles that and scales all the scenarios i mentioned...and
couldn't care less about the OPERATOR that is forwarding the call. which
btw, the operator is akin to post/get/cookie NOT where in the world the call
came from. :)

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.

the data is supposed to come. 'from' is almost irrelevant if your system is
design properly. the only expection should be cli - no post/get/cookie.

Besides that: Using $_REQUEST simply doesn't offer any advantage at all,
only slightly shorter code in some cases.

no, it allows you scale and reuse code. there are other reasons as well, the
biggest being that your system shouldn't be enforcing it's design based on a
non-enforceable construct such as input superglobals.

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

no, but i hardly see a comparison to be made here. in my db, there's only
one place i can get data. from the browser, there are several.

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.

and i'm not so concerned about that. my workmanship is confirmed superlative
not only in words, awards, and project proposals; it's also confirmed by the
caliber of the companies that keep me gainfully employed.

Of course, you can always change my mind by giving a valid reason why you
do so. I don't think there is one.

for now, let's stick to you giving me a valid reason why you should not.
your examples thus far have failed to make your case...and, i asked first.

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.

i'm making an effort to show that i understand your POV. try it sometime. :)

Sorry mate. :-/
If that is security for you, you'll have still a long way to go.

i'm well aware of that.

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.

just as get/post/request/cookie have absolutely little to do with how your
application *should* process inputs in a formal system. the 'little' being
minute enough to almost discount completely.

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?

no. i was referring to deleting a user having id 'A', years later (as you
say), someone comes back on a url query string to delete user 'A'. if you're
allowing your db to reuse id's, then that's your mistake.

as it is, you mean that 'id' is possibly in post and/or get. and, that each
context (post/get) means for 'id' has different meanings or should direct
your application to take differnt action. that's dangerous business.

what i am saying is that not recycling db "id's" and not overlapping input
hash key names ("id") and SPELLING OUT their *context* such as 'deleteId'
and 'loggedInUserId' not only takes the *magic* out of your application, it
also makes it safe to use REQUEST.

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.

no problem there. and, if you have good design, there is nothing unwise
about $_REQUEST.


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....

that's not what i'm saying. if you expect another developer to be able to
read your mind as to what meaning "id" has if it comes in via POST vs. GET
vs. COOKIE, then you had better brush up on your magic skills and the other
developer should have the name Karnack!

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'?

damn! in *your own example*, you expect a hash key of 'id'. all the while,
you expect it to have additional/specific meaning based on what superglobal
it is in. that is an implicit rule! if your other developer is not aware of
your rule, you code is shot to hell and your data will bear the results.

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

wow! assumptive, are we not?! i work every day with 22 other professional
php developers. that's just with my full-time job. i work for two other
companies as a consultant...and, i'm not alone there either.

what you've just said is a logical fallacy. look that term up, then tell me
which one it was...i'll give you a prize. :)

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."

perhaps you missed it, that ARCHITECTURE THAT DEFINES HOW THE SYSTEM WORKS.
saying 'id' has a meaning to you in POST that it doesn't in GET simply DOES
NOT DEFINE ANYTHING!!! it is magic, not architecture.

It is an open door, and has nothing to do with the topic at hand.

wow! i'm doubting your fluency and literacy. at least it's not your native
laguage, i can discount that.

Coreproblem is simply this: You are receiving your data from unknown
sources instead of pinpointing where your data comes from.

simply put as well: it should matter very little where your data comes from
as long as you have your business logic set up so that it is *decoupled*
from the input's context - whether browser or cli!

That is inferior programming compared to being more specific.
Period.

having multiple meanings for 'id' because of the superglobal housing it is
NOT specific at all to the meanining itself. can you search php doc's and
find out the specific implementation for POST as it relates to your
application? can your developer know without asking you that POST['id']
refers to the currently logged on user, and that GET['id'] means the id of
some other user that should be deleted?

the answer is no, which is why your example fails to make your case.

What architecture you use has little to do with my above statement.

it has everything to do with it. research 'decoupling', then try and bring
that knowledge back here. then tell me how you decouple your business logic
from it's implementation. then, tell me again that you're right...without
blushing. :)

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.)

the fact that it IS valid for both positions and the fact that YOU
ACKNOWLEDGE IT, simply means you've negated everything you've said! as it
was never my claim to NOT use specific superglobals, and yours that REQUEST
should be written out of the language, i thank you for declaring me the
winner of this little chat!

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 $_POST/$_GET/$_COOKIE instead of $_REQUEST will surely keep you
busy with pinpointing problems.
You haven't given me ANY reason to use $_REQUEST yet.

ahhh, editing sure makes that more accurate. and what's more, you haven't
given me ANY reason to NOT use $_REQUEST yet. as it is, i never TRIED to get
you to use it. i just asked what was wrong with using it. as it stands, i
remain unaffected and wholly unconvinced.

I think we work widely different...

perhaps. perhaps not. this is a difference of opinion to me, nothing more.

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

i'll think about it. :)


.