Re: notice and warning


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

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

as for willy-nilly deleting a user, a confirmation that the end-user really
wants to delete user x helps avoid that. however, the catch all is not
REUSING the ID in the first place. that's just asking for trouble.

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

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.

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.

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. post doesn't know
that the user is doing something they ought not do, neither does get, nor
cookie. if that's how you validate user interaction with your system, i hope
you're a good magician. you'll find another co-worker, oblivious to your
post/get/cookie 'rule' and he'll kill your how dataset of users
inadvertently. this is why we develop *architecture* that clearly defines
the condition(s) in which things can be done. 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. :)


.

Relevant Pages

  • 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: 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. ... They only have to do good clean programming, which is of course the first step to secure applications. ...
    (comp.lang.php)
  • Re: simple login script issue
    ... This script is called auth.php as in included in all of the pages I ... Example SELECT * FROM messages WHERE userid = $userid ORDER by ... I only allow a VERY restrictive set of characters for the username ...
    (alt.php)
  • LDAP search in subdomains
    ... I found a script to search for a userid in the AD. ... Set Connection = CreateObject ... My userid is in the domain eu and if I start the seach for eu it is working. ...
    (microsoft.public.windows.server.scripting)
  • Re: print to file
    ... That script shouldn't execute, there are several mistakes. ... use strict; ...
    (comp.lang.perl.misc)
Quantcast