For Programmers: Free Programming Magazines  


Home > Archive > PHP Programming > August 2006 > POST variables not coming through









You are viewing an archived Text-only version of the thread. To view this thread in it's original format and/or if you want to reply to this thread please [click here]

 

Author POST variables not coming through
WhatsPHP

2006-08-29, 6:57 pm

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_globals 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="asda@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

2006-08-29, 6:57 pm

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_globals 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="asda@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

2006-08-29, 6:57 pm

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_globals 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="asda@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_globals off, because it's horrid. Read the PHP
manual's security entry on register_globals 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_globals 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

2006-08-29, 6:57 pm

"gbbulldog" <gbbulldog@googlemail.com> wrote in
news:1156866297.045790.145340@p79g2000cwp.googlegroups.com:

> WhatsPHP wrote:
[color=darkred]
> 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

2006-08-29, 6:57 pm

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

no@emails.thx

2006-08-29, 6:57 pm

On 29 Aug 2006 10:30:47 -0700, "WhatsPHP" <futureofai@gmail.com>
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_globals 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_globals 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?


One thing I would do is to take each script in turn and change them
over to using the more correct syntax for addressing globals - like
$_POST['email'] etc - it will work fine while you have
register_globals on and when you are happy that all the necessary
scripts have been upgraded you could just switch register_globals off.
Like one of the other posters, I think the problem won't be in IE it
will be with your script corrupting the contents of those globals. So,
by changing your script to explicitly refer to them as $_POST you will
reduce the potential for confusion with local variables and hopefully
see where the problem is creeping into your script. :o)

Chris R.
Kenny

2006-08-29, 6:57 pm

On 29 Aug 2006 10:30:47 -0700, 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_globals 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_globals 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?
>


The "register_globals" setting can be easy adjusted in the php.ini config file
and would probably be a good place to start.

If you're only validating your information with Javascript, that's not very
reliable since it can be turned on and off on the client PC and you can't
control what the user is going to send back. At least a couple other people
suggested using PHP to validate the information. That way you can process the
information at the server consistently and can control how the information is
formatted and what you do with it. Javascript is not very reliable in hat regard
and shouldn't be used exclusively.

Ken
--
Newsguy's Help-A-Community Program
http://newsguy.com/charity.asp

gbbulldog

2006-08-30, 3:58 am

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_globals 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_globals 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_globals 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_globals 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_globals being on, but in the long run
it's much better if you learn to use the super-globals.

Sponsored Links







Also available: Server administration forum archive | Web Design forum archive | Software forum archive | Hardware reviews archive

Copyright 2010 codecomments.com