$_POST case sensitivity

[Bill H]

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

[Paul Lautman]

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.

[macca]

$_POST is just another array

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

strtoupper($key);

}

[Tim Roberts]

Bill H <bi**@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, ti**@probo.com
Providenza & Boekelheide, Inc.

[The Natural Philosopher]

Tim Roberts wrote:

Bill H <bi**@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.

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.

[Geoff Berrow]

Message-ID: <po********************************@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

[Jeff]

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

[larry]

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.

[Jerry Stuckle]

Geoff Berrow wrote:

Message-ID: <po********************************@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.

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.
js*******@attglobal.net
==================

[Bill H]

On Jul 6, 3:12*pm, Jerry Stuckle <[e-mail]:

Geoff Berrow wrote:

Message-ID: <[e-mail] 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.

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.
[e-mail]
==================

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

[Jerry Stuckle]

Bill H wrote:

On Jul 6, 3:12 pm, Jerry Stuckle <[e-mail]:

>Geoff Berrow wrote:

>>Message-ID: <[e-mail] 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.

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.
[e-mail]
==================

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.
js*******@attglobal.net
==================

[Paul Lautman]

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!

[macca]

blow me arse wipe.

[mike.coakley]

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

[Bill H]

On Jul 6, 7:43*pm, [e-mail] 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

[Jerry Stuckle]

mi**********@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.
js*******@attglobal.net
==================

[macca]

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.

[mike.coakley]

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

[Jerry Stuckle]

macca wrote:

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

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.
js*******@attglobal.net
==================

[Jerry Stuckle]

mi**********@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.
js*******@attglobal.net
==================

[Jerry Stuckle]

mi**********@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.
js*******@attglobal.net
==================

[Michael Fesser]

..oO(mi**********@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

[Jeff]

la***@portcommodore.com wrote:

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];

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

[Jeff]

Jerry Stuckle wrote:

mi**********@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.

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.

[mike.coakley]

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:

[e-mail] 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.

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.

[Michael Fesser]

..oO(Jeff)

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

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

[Michael Fesser]

..oO(Jeff)

>la***@portcommodore.com wrote:

>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];

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.

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

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.

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

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

Micha

[Geoff Berrow]

Message-ID: <60********************************@4ax.comfrom Michael
Fesser contained the following:

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

I can feel a 'magic quotes' moment coming on...

--
Geoff Berrow 0110001001101100010000000110
001101101011011001000110111101100111001011
100110001101101111001011100111010101101011

[Jeff]

Geoff Berrow wrote:

Message-ID: <60********************************@4ax.comfrom Michael
Fesser contained the following:

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

I can feel a 'magic quotes' moment coming on...

OK, I'll bite as I'm a php newbie. Not that I'm planning on ever using
magic quotes (I see it's deprecated) but I don't quite get the concept
of why such a functionality exists.

Is there some vulnerability this was supposed to cover up? Or is it
just a lazy way of getting data ready to put into a database? Is there
some other use?

Jeff

[Jerry Stuckle]

Jeff wrote:

Jerry Stuckle wrote:

>mi**********@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.

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,

Yes, you use htmlentities (or htmlspecialchars()), but you use it when
you output your data, not when you get it in.

You want the input string as it stands so you can parse it as necessary.
Once you're happy the string is valid, you use one or the other to
display the data.

So for instance, if the user input

Visit web page at <a href="http://www.example.com">example.com</a>!

and you want to check for any html attributes, you can search the string
for '<'. If you run the string through htmlentities() first, you have
to look for '&lt;' - which is much less clear.

But to display it in a non-text area element, you would call
htmlentities() to display it.

Also, you if you were to store the string in a database, you would want
to do it before calling htmlentities(). Again, call it just before
displaying the string (in a non-text area element).

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

[Michael Fesser]

..oO(Jeff)

>OK, I'll bite as I'm a php newbie. Not that I'm planning on ever using
magic quotes (I see it's deprecated) but I don't quite get the concept
of why such a functionality exists.

Is there some vulnerability this was supposed to cover up? Or is it
just a lazy way of getting data ready to put into a database? Is there
some other use?

It is a broken feature like register_globals. It was supposed to be an
easy to use feature to prevent SQL injection and similar problems, but
it never really worked and just led to a dangerous and false sense of
security. It will be completely removed from PHP 6, so it's not really
worth to talk about it anymore. Consider it a design mistake in PHP's
history.

Micha

[AnrDaemon]

Greetings, mi**********@gmail.com.
In reply to Your message dated Monday, July 7, 2008, 8:15:53,

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

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?

Nothing, unless you know what you want to do with it.
I.e., if you want to post it back as text (as is), just post it with
htmlspecialchars().
If you wish to allow users to use basic formatting, you must use something
like strip_tags and probably tidy module to validate input.

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

First, you must decide what you want to do. Second - understand, what you are
doing exactly. (I.e., ask yourself "why it is wrong")

>>
* *Jeff

* It is not meant to be used on input

data, and its use in that situation is incorrect.

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

I apologize if that already have been explained, but I think I'd add a word:

You MUST NOT encode any input data before processing.
Including any expressed (htmlspecialchars, htmlentities etc.) or implied
encodings (like magic_quote_gpc).

There are only one place and one case to encode data:
Place - where you sending data somewhere and
Case - to avoid damage to the target environment.

I.e., it is calling (dblayer)_escape_string() before saving data to the
database (using prepared statements will do the same), or using
htmlspecialchars() while sending data to client.

That's all.

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.

strip_tags is another ñase, and must be handled differently (and carefully).
But it would be much better example for input data preprocessing, as you
explained that already.

Thanks,

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

--
Sincerely Yours, AnrDaemon <an*******@freemail.ru>

[AnrDaemon]

Greetings, Jeff.
In reply to Your message dated Monday, July 7, 2008, 18:47:25,

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

I can feel a 'magic quotes' moment coming on...

OK, I'll bite as I'm a php newbie. Not that I'm planning on ever using
magic quotes (I see it's deprecated) but I don't quite get the concept
of why such a functionality exists.

Is there some vulnerability this was supposed to cover up? Or is it
just a lazy way of getting data ready to put into a database? Is there
some other use?

It was strange attempt to prevent SQL exploits. But it was never work good and
will be removed as I have heard.
--
Sincerely Yours, AnrDaemon <an*******@freemail.ru>