POST variables not coming through

[WhatsPHP]

Hi

For some reason, at random posts, the post variables don't get thru to
the server. For example, if there is are two text fields: name and
email... (I have register_global s on)... When I try to update the
database with a query and use $name, $email, the $name is missing or
the $email is missing. I am building an intranet application and all
the 20 or so clients run IE. This happens very rarely. Something like
once in 100 updates.

But I can see this in the log files as update contact set name="",
email="as**@pol .com" where contact_id=918. Notice the name field is
blank. I have JS checks in the client side which does not allow blank
name field..

Is this an IE random error? How do I get over this?

Weird Stuff

[adlerweb]

Maybe your user has just turned off javascript?

WhatsPHP schrieb:

Hi

For some reason, at random posts, the post variables don't get thru to
the server. For example, if there is are two text fields: name and
email... (I have register_global s on)... When I try to update the
database with a query and use $name, $email, the $name is missing or
the $email is missing. I am building an intranet application and all
the 20 or so clients run IE. This happens very rarely. Something like
once in 100 updates.

But I can see this in the log files as update contact set name="",
email="as**@pol .com" where contact_id=918. Notice the name field is
blank. I have JS checks in the client side which does not allow blank
name field..

Is this an IE random error? How do I get over this?

Weird Stuff

[gbbulldog]

WhatsPHP wrote:

Hi

For some reason, at random posts, the post variables don't get thru to
the server. For example, if there is are two text fields: name and
email... (I have register_global s on)... When I try to update the
database with a query and use $name, $email, the $name is missing or
the $email is missing. I am building an intranet application and all
the 20 or so clients run IE. This happens very rarely. Something like
once in 100 updates.

But I can see this in the log files as update contact set name="",
email="as**@pol .com" where contact_id=918. Notice the name field is
blank. I have JS checks in the client side which does not allow blank
name field..

Is this an IE random error? How do I get over this?

Weird Stuff

Firstly, turn register_global s off, because it's horrid. Read the PHP
manual's security entry on register_global s if you want to know why :)
This is also probably where your problems are coming from, as variables
are really easily over-written when register_global s is on.

Secondly, don't just validate in JS - validate in PHP too, as the JS
might not run as expected or may be ignored completely if a (malicious)
user decides to create their own POST to the form handler.

[Good Man]

"gbbulldog" <gb*******@goog lemail.comwrote in
news:11******** **************@ p79g2000cwp.goo glegroups.com:

WhatsPHP wrote:

>I have JS checks in the client side which does not allow blank

Secondly, don't just validate in JS - validate in PHP too, as the JS
might not run as expected or may be ignored completely if a
(malicious) user decides to create their own POST to the form handler.

You will never get better advice than this. You *must* get a handle on
security whenever you are using PHP and submitted forms.

*NEVER* trust user input. You must *ALWAYS* validate your info on the
PHP side - make sure that you are actually getting the information you
are expecting. As noted above, if a user has disabled javascript, then
they can submit an empty form. Heck, I don't even need to VISIT a
website to submit information to the form on it - I can post to a FORM
via command-line, or any other number of ways, without hitting the
original form.

So how would you guard against people submitting a 'fake' form from
their own computer, or just turning off javascript? By checking *ALL
USER INPUT*. It is the FIRST RULE involving ANY server-side scripting
language - VALIDATE USER INPUT!

As you can see, this point simply CANNOT be stressed enough. It is the
first hole (and biggest) that must be plugged in everything you write
from this day forth.

:)

[WhatsPHP]

Thanks for all your input on security guys i will certainly keep it in
mind, but this is an inhouse intranet application and the users who use
the system barely know how to use it, let alone hack it.. That is the
reason we had register_global s on. This system maybe internal and on
the intranet but it has around 20 people using it full time (so it is
not small)..

We have register_global s on.. What is still bugging me is the totally
random occurence of this error.. has anyone experienced IE behaving
weird by not posting all the form variables, both hidden and non-hidden
as it should?

[gbbulldog]

WhatsPHP wrote:

Thanks for all your input on security guys i will certainly keep it in
mind, but this is an inhouse intranet application and the users who use
the system barely know how to use it, let alone hack it.. That is the
reason we had register_global s on. This system maybe internal and on
the intranet but it has around 20 people using it full time (so it is
not small)..

We have register_global s on.. What is still bugging me is the totally
random occurence of this error.. has anyone experienced IE behaving
weird by not posting all the form variables, both hidden and non-hidden
as it should?

If the JavaScript fails at any time and you're relying on using an
"onSubmit" check to validate the data, the data won't be validated at
all! Validation is not just a question of security - it's good practice
to stop your scripts from failing, esp. when working with databases.

Again, the inherant problems with having register_global s on aren't all
security related, either. When it's turned on, $_POST['name'] would be
the same as $_GET['name'], which is the same as $name - all sorts of
bother!

Another problem with having register_global s on is session
over-writing. Say you authenticate a user and store the user's id in
the session variable $_SESSION['id']. If you then assign the variable
$id with a value anywhere else on a page which the user visits,
$_SESSION['id'] will be over-written with $id!

I know it's a pain to alter your scripts and change over to a system
which doesn't rely on register_global s being on, but in the long run
it's much better if you learn to use the super-globals.