I wouldn't consider myself a newbie to PHP since I have never written
one line of code in it (am a perl guy myself), but part of a team I am
working with is writing some php interfaces into a database and I
noticed that they are relaying on HTML form value names to always be
lowercase in their code (ie $_POST['save'] (fyi that may be typed
wrong)) and from my experience it is always better, when reading in
the post information to convert the the form value name to uppercase
on the off chance that one web page may have NAME="save" and another
may have NAME="Save", this way you can will always get the value.

In perl this is easy cause you are pulling in the name / value pairs
straight from the ENV value. But since, from what I see and they say,
PHP does this for you and puts it into $_POST, is there a way to tell
PHP to always convert the name of the value to uppercase?

Bill H

Bill H wrote:

>I wouldn't consider myself a newbie to PHP since I have never written
one line of code in it (am a perl guy myself), but part of a team I am
working with is writing some php interfaces into a database and I
noticed that they are relaying on HTML form value names to always be
lowercase in their code (ie $_POST['save'] (fyi that may be typed
wrong)) and from my experience it is always better, when reading in
the post information to convert the the form value name to uppercase
on the off chance that one web page may have NAME="save" and another
may have NAME="Save", this way you can will always get the value.

In my experience php scripts are written to interact with specific web
pages. You code the web page to match the script that will process its
input.

$_POST is just another array

foreach ($_POST as $key=>$value){

strtoupper($key);

}

Bill H <bill@ts1000.uswrote:

>
>...
>I noticed that they are relaying on HTML form value names to always be
>lowercase in their code (ie $_POST['save'] (fyi that may be typed
>wrong))

Nope, that's correct.

>...and from my experience it is always better, when reading in
>the post information to convert the the form value name to uppercase
>on the off chance that one web page may have NAME="save" and another
>may have NAME="Save", this way you can will always get the value.

I find this philosophy interesting. Because these names ARE
case-sensitive, I would consider it a programming error to use different
spellings in different web pages. It seems to me that this kind of
mangling is just hiding errors and inconsistancies. I mean, if the company
standard is that "<inputfield names should always be in lower case", then
by golly they should always be in lower case, and a programmer who writes
NAME="Save" has committed an error.
--
Tim Roberts, timr@probo.com
Providenza & Boekelheide, Inc.

Tim Roberts wrote:

Bill H <bill@ts1000.uswrote:

>
Nope, that's correct.
>

>
I find this philosophy interesting. Because these names ARE
case-sensitive, I would consider it a programming error to use different
spellings in different web pages. It seems to me that this kind of
mangling is just hiding errors and inconsistancies. I mean, if the company
standard is that "<inputfield names should always be in lower case", then
by golly they should always be in lower case, and a programmer who writes
NAME="Save" has committed an error.

And you end up with the sort of mess this computer is in.
I decided to include case sensitivity in the OS-X re-format. Now I cant
install Adobe CS3.

Adobe being Mac people have always relied on the fact that case didn't
matter.

And can't cope with life when it does.

Its a pain when I have a pair of directories on a samba mount called
images and Images, and he computer wrecks the whole file system trying
to work out which is which.

Message-ID: <poj074df5uogtch41qe5ujc2ells58m1fv@4ax.comfrom Tim
Roberts contained the following:

>I find this philosophy interesting. Because these names ARE
>case-sensitive, I would consider it a programming error to use different
>spellings in different web pages.

Agreed but it may be sensible to allow for the possibility of the use of
incorrect case if the people preparing the html are not programmers.
Thanks to Bill Gates there are a lot of people who do not recognise that
case sensitivity exists.
--
Geoff Berrow 0110001001101100010000000110
001101101011011001000110111101100111001011
100110001101101111001011100111010101101011

Bill H wrote:

I wouldn't consider myself a newbie to PHP since I have never written
one line of code in it (am a perl guy myself), but part of a team I am
working with is writing some php interfaces into a database and I
noticed that they are relaying on HTML form value names to always be
lowercase in their code (ie $_POST['save'] (fyi that may be typed
wrong)) and from my experience it is always better, when reading in
the post information to convert the the form value name to uppercase
on the off chance that one web page may have NAME="save" and another
may have NAME="Save", this way you can will always get the value.
>
In perl this is easy cause you are pulling in the name / value pairs
straight from the ENV value. But since, from what I see and they say,
PHP does this for you and puts it into $_POST, is there a way to tell
PHP to always convert the name of the value to uppercase?

Not tested. My PHP is not great, but why not:

foreach($_POST as $key){
$_POST[strtoupper($key)]=$_POST[$key];
}

Jeff

>
Bill H

On Jul 6, 10:37 am, Jeff <jeff@spam_me_not.comwrote:

Not tested. My PHP is not great, but why not:
>
foreach($_POST as $key){
$_POST[strtoupper($key)]=$_POST[$key];
>
}
>

It would be more like:

$strtoupper($_POST[$key]) = $_POST[$key];

If that doesn't work this will:

$var = strtoupper($_POST[$key]);
$$var = $_POST[$key];

note: Always make sure you validate/filter any POST data that could
lead to vulnerabilities.

Geoff Berrow wrote:

Message-ID: <poj074df5uogtch41qe5ujc2ells58m1fv@4ax.comfrom Tim
Roberts contained the following:
>

>
>
Agreed but it may be sensible to allow for the possibility of the use of
incorrect case if the people preparing the html are not programmers.
Thanks to Bill Gates there are a lot of people who do not recognise that
case sensitivity exists.

Nope, just teach them the correct way to do it. It's never a good idea
to hide programming problems. They always come back to haunt you in the
end. And by that time they are much more expensive to fix than they
would have been if the job had been done right in the first place.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

On Jul 6, 3:12*pm, Jerry Stuckle <jstuck...@attglobal.netwrote:

Geoff Berrow wrote:

>

>

>
Nope, just teach them the correct way to do it. *It's never a good idea
to hide programming problems. *They always come back to haunt you in the
end. *And by that time they are much more expensive to fix than they
would have been if the job had been done right in the first place.
>
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstuck...@attglobal.net
==================

Agreed they should always follow a set way, all form value names
uppercase (or lowercase), but you never know what someone may do
without thinking in the future. On the perl side, I try to always make
my form value names uppercase so they will always work with a cgi I
may have written awhile back, but by having this catch in there
(converting the key to uppercase) I never have to wonder if the form
valeu name is the reason why it somethign didn't work the way I
expected.

All the examples I have seen here (and thanks for them) all seem to be
making a 2nd entry in the $_POST array with the key value corrected to
uppercase. So am I correct in assuming you can't just tell PHP to do
it?

Bill H

Bill H wrote:

On Jul 6, 3:12 pm, Jerry Stuckle <jstuck...@attglobal.netwrote:

>
Agreed they should always follow a set way, all form value names
uppercase (or lowercase), but you never know what someone may do
without thinking in the future. On the perl side, I try to always make
my form value names uppercase so they will always work with a cgi I
may have written awhile back, but by having this catch in there
(converting the key to uppercase) I never have to wonder if the form
valeu name is the reason why it somethign didn't work the way I
expected.
>
All the examples I have seen here (and thanks for them) all seem to be
making a 2nd entry in the $_POST array with the key value corrected to
uppercase. So am I correct in assuming you can't just tell PHP to do
it?
>
Bill H
>

No, PHP is case sensitive, just like HTML is. And that is the correct
way to do things.

You need standards on how to do things, and people need to follow those
standards. Otherwise, you have chaos. And if they do something else in
the future, the code breaks. That's simple.

But as an example as to why you shouldn't do it -

<input type=text name="NAME" ...>

Now what happens if later someone comes along with:

<input type=hidden name="name" ...>

In over 40 years of programming, I've seen things like this happen way
too many times because, rather than enforcing standards, someone tried
to cover up errors.

But when you set standards and enforce them, you have fewer errors in
the code, and find those errors earlier in the development process.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

macca wrote:

$_POST is just another array
>
foreach ($_POST as $key=>$value){
>
strtoupper($key);
>
}

I KNOW that! What the !¬"!££$£$ are you telling me for?

Learn how to post replies!

blow me arse wipe.

If all you are tying to do is uppercase (or lowercase - whatever) the
key names of an array you can use the PHP function
array_change_key_case.

http://us.php.net/manual/en/function...e-key-case.php

It can change the values to upper or lower case depending upon the way
you call it. No need to build your own iterator.

So in your case: $_POST = array_change_key_case($_POST, CASE_UPPER);

BUT of course as someone else mentioned you should always NOT TRUST
input from the web so you should probably iterate over the $_POST
array anyway so do something like this:

$myPost = $_POST;
$_POST = array();
while (list($key, $value) = each($myPost)) {
$_POST[strtoupper($key)] = htmlentities($value);
}

Of course there are a million ways to to this and the htmlentities
(see http://us3.php.net/manual/en/function.htmlentities.php) might not
be how you want to handle input "cleansing" but this is a start.

Thanks,

Mike

On Jul 6, 7:43*pm, mike.coak...@gmail.com wrote:

If all you are tying to do is uppercase (or lowercase - whatever) the
key names of an array you can use the PHP function
array_change_key_case.
>
http://us.php.net/manual/en/function...e-key-case.php
>
It can change the values to upper or lower case depending upon the way
you call it. No need to build your own iterator.
>
So in your case: $_POST = array_change_key_case($_POST, CASE_UPPER);
>
BUT of course as someone else mentioned you should always NOT TRUST
input from the web so you should probably iterate over the $_POST
array anyway so do something like this:
>
$myPost = $_POST;
$_POST = array();
while (list($key, $value) = each($myPost)) {
* $_POST[strtoupper($key)] = htmlentities($value);
>
}
>
Of course there are a million ways to to this and the htmlentities
(seehttp://us3.php.net/manual/en/function.htmlentities.php) might not
be how you want to handle input "cleansing" but this is a start.
>
Thanks,
>
Mike

Thanks Mike - this is what I am looking for. The problem I forsee and
am trying to avoid is after the database guys get done building their
php pages to interface with the database and the designers then take
over them in dreamweaver that they may mess form element names up
without realizing what they are doing since they don't no anythign
about programming, they just make the pages "pretty".

Bill H

mike.coakley@gmail.com wrote:

If all you are tying to do is uppercase (or lowercase - whatever) the
key names of an array you can use the PHP function
array_change_key_case.
>
http://us.php.net/manual/en/function...e-key-case.php
>
It can change the values to upper or lower case depending upon the way
you call it. No need to build your own iterator.
>
So in your case: $_POST = array_change_key_case($_POST, CASE_UPPER);
>
BUT of course as someone else mentioned you should always NOT TRUST
input from the web so you should probably iterate over the $_POST
array anyway so do something like this:
>
$myPost = $_POST;
$_POST = array();
while (list($key, $value) = each($myPost)) {
$_POST[strtoupper($key)] = htmlentities($value);
}
>
Of course there are a million ways to to this and the htmlentities
(see http://us3.php.net/manual/en/function.htmlentities.php) might not
be how you want to handle input "cleansing" but this is a start.
>
Thanks,
>
Mike
>
>
>
>

htmlentities() has nothing to do with this request - and, if used, will
cause problems.

But I'm not trying to do any of that. Please learn how to reply properly.


--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

That the best you can do? *

What's it got to do with you?

When someone insults you for a simple mistake, when your intentions
are good and you are trying to help someone it's not good netiquette
and doesn't deserve more than about 3 seconds of my time, if that.

>Please learn how to reply properly.

is a more reasonable response.

Jerry,

I can appreciate your view point. Maybe I did assume too much with my
reply. I was assuming that Bill would understand my intention with
first giving him the answer he was looking for (array_change_key_case)
and then expanding to fulfill a comment someone else made in the
posts, to me if you are iterating over the data received from a HTML
form you should only iterate once if possible and that is why I made
the natural "leap" to offer some filtering advice as well.

So... BILL - please understand that all you need to use is
array_change_key_case to resolve the issue you have requested within
this topic. However, off topic of course, you can use htmlentities to
encode/filter HTML form data received via the $_POST array to
effectively strip the users input of HTML entities while still
retaining their display value. (Definitely read the linked docs in my
last reply.) You absolutely should understand what issues htmlentities
could cause your data input routines and ensure that all of those
involved understand how its filtering will affect your workflow.

Jerry - if you would, even off list - let me know the issues you have
had with htmlentities. I've used it for a while now and would like to
know what problems it can cause.

Thanks,

Mike

macca wrote:

>
What's it got to do with you?
>
When someone insults you for a simple mistake, when your intentions
are good and you are trying to help someone it's not good netiquette
and doesn't deserve more than about 3 seconds of my time, if that.
>

>
is a more reasonable response.
>

Don't worry. Gary is a well-known troll. He never has contributed
anything of value to this newsgroup.

In fact, he has to run his own news server because he's been kicked off
so many others for his actions. And he's still upset with me because he
tried to cross-post a thread to another newsgroup and blame me for the
cross-posting. And when I was able to prove it was him who initiated
the cross-post - and the message he used to do it, all he could do was
call me "liar".

He's been plonked not only by most regular users of this newsgroup, but
many users on usenet. Even his news server has been blocked by some
other news servers. Too bad they don't all do it.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

mike.coakley@gmail.com wrote:

Jerry,
>
I can appreciate your view point. Maybe I did assume too much with my
reply. I was assuming that Bill would understand my intention with
first giving him the answer he was looking for (array_change_key_case)
and then expanding to fulfill a comment someone else made in the
posts, to me if you are iterating over the data received from a HTML
form you should only iterate once if possible and that is why I made
the natural "leap" to offer some filtering advice as well.
>
So... BILL - please understand that all you need to use is
array_change_key_case to resolve the issue you have requested within
this topic. However, off topic of course, you can use htmlentities to
encode/filter HTML form data received via the $_POST array to
effectively strip the users input of HTML entities while still
retaining their display value. (Definitely read the linked docs in my
last reply.) You absolutely should understand what issues htmlentities
could cause your data input routines and ensure that all of those
involved understand how its filtering will affect your workflow.
>
Jerry - if you would, even off list - let me know the issues you have
had with htmlentities. I've used it for a while now and would like to
know what problems it can cause.
>
Thanks,
>
Mike
>

htmlentities() is not the correct function to use here. It is used to
write strings which may contain html special characters (like '<' and
'>', for instance) to an html page. It is not meant to be used on input
data, and its use in that situation is incorrect.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

mike.coakley@gmail.com wrote:

Jerry,
>
I can appreciate your view point. Maybe I did assume too much with my
reply. I was assuming that Bill would understand my intention with
first giving him the answer he was looking for (array_change_key_case)
and then expanding to fulfill a comment someone else made in the
posts, to me if you are iterating over the data received from a HTML
form you should only iterate once if possible and that is why I made
the natural "leap" to offer some filtering advice as well.
>
So... BILL - please understand that all you need to use is
array_change_key_case to resolve the issue you have requested within
this topic. However, off topic of course, you can use htmlentities to
encode/filter HTML form data received via the $_POST array to
effectively strip the users input of HTML entities while still
retaining their display value. (Definitely read the linked docs in my
last reply.) You absolutely should understand what issues htmlentities
could cause your data input routines and ensure that all of those
involved understand how its filtering will affect your workflow.
>
Jerry - if you would, even off list - let me know the issues you have
had with htmlentities. I've used it for a while now and would like to
know what problems it can cause.
>
Thanks,
>
Mike
>

I should also say - changing the case of the $_POST array keys does not
solve a problem. It only masks the problem. And such masking will
always come back to bite you, sooner or later.

The solution is simple. Set standards and enforce them.

YoU dON't ThINk eDITOrS aLLow PEoplE tO USe jUSt aNY CASe tHeY wANt, dO
YOU?

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

..oO(mike.coakley@gmail.com)

>So... BILL - please understand that all you need to use is
>array_change_key_case to resolve the issue you have requested within
>this topic. However, off topic of course, you can use htmlentities to
>encode/filter HTML form data received via the $_POST array to
>effectively strip the users input of HTML entities while still
>retaining their display value.

Wrong! htmlentities() and htmlspecialchars() are meant for output to an
HTML page, but never (never!) for sanitizing input data.

(Definitely read the linked docs in my
>last reply.) You absolutely should understand what issues htmlentities
>could cause your data input routines

Exactly, because it's the totally wrong tool here. It will change your
data, which makes further processing more complicated. Additionally it
won't prevent SQL injection attacks for example.

>and ensure that all of those
>involved understand how its filtering will affect your workflow.

You always want to work with the _raw_ unescaped data and only apply
escaping functions where necessary. Which functions to use depends on
what you actually want to do with the data.

Micha

larry@portcommodore.com wrote:

On Jul 6, 10:37 am, Jeff <jeff@spam_me_not.comwrote:
>

It would be more like:
>
$strtoupper($_POST[$key]) = $_POST[$key];

I think I read this differently than you. I thought he wanted uppercase
keys... you may be right. The OPs post is as little ambiguous.

>
If that doesn't work this will:
>
$var = strtoupper($_POST[$key]);
$$var = $_POST[$key];

^^ What does the double "$" do? Is that a reference? I'd look it up
if I knew what it was called!

>
note: Always make sure you validate/filter any POST data that could
lead to vulnerabilities.

Perl guys are used to the "taint" -T switch. I suspect there isn't a php
equivalent.

Jeff

Jerry Stuckle wrote:

mike.coakley@gmail.com wrote:

>
htmlentities() is not the correct function to use here. It is used to
write strings which may contain html special characters (like '<' and
'>', for instance) to an html page.

Say we have a textarea:

<textarea$value </textarea>

What would be the proper processing needed for $value? I'm using
htmlentities for my textfields and selects and I assume that is correct,
but $value could contain html and I'm unsure what to do there as I don't
want to turn <brinto &lt;br&gt; but I also don't want to break this if

there is a textarea tag in $value.

Jeff


It is not meant to be used on input

data, and its use in that situation is incorrect.
>

Jeff,

Jerry & Micha are absolutely correct in their statements about
htmlentities. I will say that my comments on input validation/
filtering probably were a little presumptuous on my part. I personally
don't allow ANY HTML tags to be entered into my HTML forms and
therefore I use htmlentities as a pre-processor BUT the intention is
to use it during output. Using htmlentities will protect against Cross-
site scripting issues and not SQL injection as Micha pointed out. Most
likely what you are looking for the strip_tags function (http://
us3.php.net/manual/en/function.strip-tags.php) and pass it a string of
the tags you want to slip through.

Thanks,

Mike

(OF course I'm probably reading this wrong as well and this is REALLY
OT... but I hope I helped a little.)

On Jul 6, 11:45*pm, Jeff <jeff@spam_me_not.comwrote:

Jerry Stuckle wrote:

>

>

>

>

>

>

>
Say we have a textarea:
>
<textarea$value </textarea>
>
What would be the proper processing needed for $value? I'm using
htmlentities for my textfields and selects and I assume that is correct,
but $value could contain html and I'm unsure what to do there as I don't
want to turn <brinto &lt;br&gt; but I also don't want to break this if
>
there is a textarea tag in $value.
>
* *Jeff
>
* It is not meant to be used on input
>

>
>

..oO(Jeff)

>Jerry Stuckle wrote:

>
>Say we have a textarea:
>
><textarea$value </textarea>
>
>What would be the proper processing needed for $value?

htmlentities() or htmlspecialchars(). The latter is preferred, since
with a proper encoding (UTF-8 for example) there's no need for any
character references except for the ones used by htmlspecialchars().

>I'm using
>htmlentities for my textfields and selects and I assume that is correct,

It is correct.

>but $value could contain html and I'm unsure what to do there as I don't
>want to turn <brinto &lt;br&gt; but I also don't want to break this if
>
>there is a textarea tag in $value.

The content of a textarea is seen as-is, there's no interpretation of
HTML elements. Character references like &foo; are resolved, though. If
you apply htmlspecialchars() to the data, you should get the correct and
intended output.

Micha

..oO(Jeff)

>larry@portcommodore.com wrote:

>
>I think I read this differently than you. I thought he wanted uppercase
>keys... you may be right. The OPs post is as little ambiguous.

This code is just wrong. Yours looks better.

>
^^ What does the double "$" do? Is that a reference? I'd look it up
>if I knew what it was called!

It's called "variable variables", which means that the value of one
variable is taken as the name of another one:

$foo = 'bar';
$$foo = 42; // sets a variable, whose name is taken from $foo
print $bar; // will print '42'

Generally spoken you should avoid such structures. They make the code
more error-prone and much harder to debug. In most cases where variable
variables are usually used an array would have been the better choice.

>
>Perl guys are used to the "taint" -T switch. I suspect there isn't a php
>equivalent.

Correct. All user data (really all: GET, POST, COOKIE) should be
considered tainted and handled accordingly.

Micha