POST action

[iccsi]

<form action="action.php" method="post">
<p>Your name: <input type="text" name="name" /></p>
<p>Your age: <input type="text" name="age" /></p>
<p><input type="submit" /></p>
</form>In the PHP tutorial manual, it says that we can have post action to
the form itself just like above coding.I would like to know in the real
projects, can we have action to the same PHP file, since that we only need
have one filebut not 2 files foe POST request,Your help and information is
great appreciated,regards,Iccsi,

[Larry Garfield]

Post by iccsi
<form action="action.php" method="post">
<p>Your name: <input type="text" name="name" /></p>
<p>Your age: <input type="text" name="age" /></p>
<p><input type="submit" /></p>
</form>In the PHP tutorial manual, it says that we can have post
action to the form itself just like above coding.I would like to know
in the real projects, can we have action to the same PHP file, since
that we only need have one filebut not 2 files foe POST request,Your
help and information is great appreciated,regards,Iccsi,

"Real" projects to all kinds of things. Which is best depends on who
you ask. :-)

I would argue that there's 3 "good" approaches, both of which are viable:

1) Define your form abstractly via an API, and have the API detect the
presence of POST request and then process the form after it's built.
That means you do submit back to the same URL. (Drupal 7 and earlier do
this.)

2) Put 2 separate request handlers / controllers at the same path, one
for GET and one for POST. So you submit back to the same URL but an
entirely different piece of code responds to it. (This requires a good
routing system that can differentiate between GET and POST.)

3) Every form is defined as its own object somewhere with a unique ID.
All forms post to the same URL but include the form ID. Code at that
URL looks up the form object by ID and maps the submitted data to it to
know what to do with it.

Note that in all 3 cases you're defining a form via an API of some
kind. You are not writing form tags yourself. Don't do that. Ever. I
promise you that you will have a security hole or six if you do. Use a
good form handling API for building forms. That's what good "Real"
projects do. There are a lot out there. Most fullstack frameworks or
CMSes have one built in (I know Drupal and Code Ignighter do, although
they're quite different), and there are reasonably stand-alone
components available in both Symfony2 Components and Zend Framework.
Please don't write your own. There are too many good ones (and even
more bad ones, of course) already out there that have been security
hardened.

--Larry Garfield

[Jim Giner]

Post by Larry Garfield

Post by iccsi
<form action="action.php" method="post">
<p>Your name: <input type="text" name="name" /></p>
<p>Your age: <input type="text" name="age" /></p>
<p><input type="submit" /></p>
</form>In the PHP tutorial manual, it says that we can have post
action to the form itself just like above coding.I would like to know
in the real projects, can we have action to the same PHP file, since
that we only need have one filebut not 2 files foe POST request,Your
help and information is great appreciated,regards,Iccsi,

"Real" projects to all kinds of things. Which is best depends on who
you ask. :-)
1) Define your form abstractly via an API, and have the API detect the
presence of POST request and then process the form after it's built.
That means you do submit back to the same URL. (Drupal 7 and earlier do
this.)
2) Put 2 separate request handlers / controllers at the same path, one
for GET and one for POST. So you submit back to the same URL but an
entirely different piece of code responds to it. (This requires a good
routing system that can differentiate between GET and POST.)
3) Every form is defined as its own object somewhere with a unique ID.
All forms post to the same URL but include the form ID. Code at that
URL looks up the form object by ID and maps the submitted data to it to
know what to do with it.
Note that in all 3 cases you're defining a form via an API of some
kind. You are not writing form tags yourself. Don't do that. Ever. I
promise you that you will have a security hole or six if you do. Use a
good form handling API for building forms. That's what good "Real"
projects do. There are a lot out there. Most fullstack frameworks or
CMSes have one built in (I know Drupal and Code Ignighter do, although
they're quite different), and there are reasonably stand-alone
components available in both Symfony2 Components and Zend Framework.
Please don't write your own. There are too many good ones (and even
more bad ones, of course) already out there that have been security
hardened.
--Larry Garfield

Never write your own form? I'm guilty - oh, so guilty. What exactly is
a 'security hardened' form?

IN answer to OP - yes you can use a single script to handle your from
return. I do that too! I start by recognizing my first time thru and
send out a form/page. I process the submit back from that page, doing
something based on the label of the submit button that I detect. I may
then do some more processing and produce a newer version of the same
form/page and repeat. Or I may end it all at that point. Depends on
what the overall appl is doing.

And now I'll watch and see how much I'm doing wrong.

[Ashley Sheridan]

Post by Jim Giner

Post by Larry Garfield

Post by iccsi
<form action="action.php" method="post">
<p>Your name: <input type="text" name="name" /></p>
<p>Your age: <input type="text" name="age" /></p>
<p><input type="submit" /></p>
</form>In the PHP tutorial manual, it says that we can have post
action to the form itself just like above coding.I would like to know
in the real projects, can we have action to the same PHP file, since
that we only need have one filebut not 2 files foe POST request,Your
help and information is great appreciated,regards,Iccsi,

"Real" projects to all kinds of things. Which is best depends on who
you ask. :-)
1) Define your form abstractly via an API, and have the API detect the
presence of POST request and then process the form after it's built.
That means you do submit back to the same URL. (Drupal 7 and earlier do
this.)
2) Put 2 separate request handlers / controllers at the same path, one
for GET and one for POST. So you submit back to the same URL but an
entirely different piece of code responds to it. (This requires a good
routing system that can differentiate between GET and POST.)
3) Every form is defined as its own object somewhere with a unique ID.
All forms post to the same URL but include the form ID. Code at that
URL looks up the form object by ID and maps the submitted data to it to
know what to do with it.
Note that in all 3 cases you're defining a form via an API of some
kind. You are not writing form tags yourself. Don't do that. Ever. I
promise you that you will have a security hole or six if you do. Use a
good form handling API for building forms. That's what good "Real"
projects do. There are a lot out there. Most fullstack frameworks or
CMSes have one built in (I know Drupal and Code Ignighter do, although
they're quite different), and there are reasonably stand-alone
components available in both Symfony2 Components and Zend Framework.
Please don't write your own. There are too many good ones (and even
more bad ones, of course) already out there that have been security
hardened.
--Larry Garfield

Never write your own form? I'm guilty - oh, so guilty. What exactly is
a 'security hardened' form?
IN answer to OP - yes you can use a single script to handle your from
return. I do that too! I start by recognizing my first time thru and
send out a form/page. I process the submit back from that page, doing
something based on the label of the submit button that I detect. I may
then do some more processing and produce a newer version of the same
form/page and repeat. Or I may end it all at that point. Depends on
what the overall appl is doing.
And now I'll watch and see how much I'm doing wrong.

I don't think there's anything inherently wrong with writing your own
form processing code, as long as you understand what's going on. Many
frameworks do make this a lot easier though, but sometimes I find it
encourages you to ignore some of the details (like security) because you
"know" the framework handles that stuff.

I would say code forms on your own first, as a learning experience, then
use frameworks once you know what you're doing.

Thanks,
Ash
http://www.ashleysheridan.co.uk

[Jim Giner]

Post by Ashley Sheridan

Post by Jim Giner

Post by Larry Garfield

Post by iccsi
<form action="action.php" method="post">
<p>Your name: <input type="text" name="name" /></p>
<p>Your age: <input type="text" name="age" /></p>
<p><input type="submit" /></p>
</form>In the PHP tutorial manual, it says that we can have post
action to the form itself just like above coding.I would like to know
in the real projects, can we have action to the same PHP file, since
that we only need have one filebut not 2 files foe POST request,Your
help and information is great appreciated,regards,Iccsi,

"Real" projects to all kinds of things. Which is best depends on who
you ask. :-)
1) Define your form abstractly via an API, and have the API detect the
presence of POST request and then process the form after it's built.
That means you do submit back to the same URL. (Drupal 7 and earlier do
this.)
2) Put 2 separate request handlers / controllers at the same path, one
for GET and one for POST. So you submit back to the same URL but an
entirely different piece of code responds to it. (This requires a good
routing system that can differentiate between GET and POST.)
3) Every form is defined as its own object somewhere with a unique ID.
All forms post to the same URL but include the form ID. Code at that
URL looks up the form object by ID and maps the submitted data to it to
know what to do with it.
Note that in all 3 cases you're defining a form via an API of some
kind. You are not writing form tags yourself. Don't do that. Ever. I
promise you that you will have a security hole or six if you do. Use a
good form handling API for building forms. That's what good "Real"
projects do. There are a lot out there. Most fullstack frameworks or
CMSes have one built in (I know Drupal and Code Ignighter do, although
they're quite different), and there are reasonably stand-alone
components available in both Symfony2 Components and Zend Framework.
Please don't write your own. There are too many good ones (and even
more bad ones, of course) already out there that have been security
hardened.
--Larry Garfield

Never write your own form? I'm guilty - oh, so guilty. What exactly is
a 'security hardened' form?
IN answer to OP - yes you can use a single script to handle your from
return. I do that too! I start by recognizing my first time thru and
send out a form/page. I process the submit back from that page, doing
something based on the label of the submit button that I detect. I may
then do some more processing and produce a newer version of the same
form/page and repeat. Or I may end it all at that point. Depends on
what the overall appl is doing.
And now I'll watch and see how much I'm doing wrong.

I don't think there's anything inherently wrong with writing your own
form processing code, as long as you understand what's going on. Many
frameworks do make this a lot easier though, but sometimes I find it
encourages you to ignore some of the details (like security) because
you "know" the framework handles that stuff.
I would say code forms on your own first, as a learning experience,
then use frameworks once you know what you're doing.
Thanks,
Ash
http://www.ashleysheridan.co.uk

I dont' know that i'll ever use a framework. Strictly an
ex-professional here doing my own website stuff. As you say 'code your
own forms first as a learning experience'. Well, once I've coded them
(aside: I think you mean 'process', not code) and learned how to do it
right, why should I give up that task and pick up a framework?

[Robert Cummings]

Post by Jim Giner

Post by Ashley Sheridan

Post by Jim Giner

Post by Larry Garfield

Post by iccsi
<form action="action.php" method="post">
<p>Your name: <input type="text" name="name" /></p>
<p>Your age: <input type="text" name="age" /></p>
<p><input type="submit" /></p>
</form>In the PHP tutorial manual, it says that we can have post
action to the form itself just like above coding.I would like to know
in the real projects, can we have action to the same PHP file, since
that we only need have one filebut not 2 files foe POST request,Your
help and information is great appreciated,regards,Iccsi,

"Real" projects to all kinds of things. Which is best depends on who
you ask. :-)
1) Define your form abstractly via an API, and have the API detect the
presence of POST request and then process the form after it's built.
That means you do submit back to the same URL. (Drupal 7 and earlier do
this.)
2) Put 2 separate request handlers / controllers at the same path, one
for GET and one for POST. So you submit back to the same URL but an
entirely different piece of code responds to it. (This requires a good
routing system that can differentiate between GET and POST.)
3) Every form is defined as its own object somewhere with a unique ID.
All forms post to the same URL but include the form ID. Code at that
URL looks up the form object by ID and maps the submitted data to it to
know what to do with it.
Note that in all 3 cases you're defining a form via an API of some
kind. You are not writing form tags yourself. Don't do that. Ever. I
promise you that you will have a security hole or six if you do. Use a
good form handling API for building forms. That's what good "Real"
projects do. There are a lot out there. Most fullstack frameworks or
CMSes have one built in (I know Drupal and Code Ignighter do, although
they're quite different), and there are reasonably stand-alone
components available in both Symfony2 Components and Zend Framework.
Please don't write your own. There are too many good ones (and even
more bad ones, of course) already out there that have been security
hardened.
--Larry Garfield

Never write your own form? I'm guilty - oh, so guilty. What exactly is
a 'security hardened' form?
IN answer to OP - yes you can use a single script to handle your from
return. I do that too! I start by recognizing my first time thru and
send out a form/page. I process the submit back from that page, doing
something based on the label of the submit button that I detect. I may
then do some more processing and produce a newer version of the same
form/page and repeat. Or I may end it all at that point. Depends on
what the overall appl is doing.
And now I'll watch and see how much I'm doing wrong.

I don't think there's anything inherently wrong with writing your own
form processing code, as long as you understand what's going on. Many
frameworks do make this a lot easier though, but sometimes I find it
encourages you to ignore some of the details (like security) because
you "know" the framework handles that stuff.
I would say code forms on your own first, as a learning experience,
then use frameworks once you know what you're doing.
Thanks,
Ash
http://www.ashleysheridan.co.uk

I dont' know that i'll ever use a framework. Strictly an
ex-professional here doing my own website stuff. As you say 'code your
own forms first as a learning experience'. Well, once I've coded them
(aside: I think you mean 'process', not code) and learned how to do it
right, why should I give up that task and pick up a framework?

Chances are, once you've done this yourself and abstracted away the
implementation details, you have your own framework for performing this
generally tedious task :)

Cheers,
Rob.

[Larry Garfield]

Post by Ashley Sheridan

Post by Jim Giner
Never write your own form? I'm guilty - oh, so guilty. What exactly is
a 'security hardened' form?

- All forms need a valid CSRF token to avoid CSRF attacks. This needs
to be matched between the submitted form and server-maintained state.
Do all of your forms have that? Every single one? (A GET lookup form
like a search box doesn't need it, but anything with POST does, I'd argue.)

- Do you have a select element? Do you have error handling for when
someone submits a value for that wasn't one of the option elements?

- Your text input field has a max length of 20. Does your code return an
error when the user enters a string of 100 characters?

- Are you checking for weird edge-case-y character encoding issues?
(Some versions of some browsers can be hacked by sending UTF-7 instead
of UTF-8 for certain parts of the request. I don't fully understand that
stuff myself, either.)

- You have a "number" field (HTML5). Does your PHP code handle someone
submitting a string anyway?

- Are you checking all of those correctly every single time you write a
form?

Remember, a form POST is not a form submission. It's a wide open RPC
call for the entire Internet, for which you provide casual suggestions
via HTML. Always assume an attacker bypasses the HTML and just POSTs
variables right at your server. I'm probably forgetting a few things in
the list above, too.

Hence, for 98% of cases, if you're writing your own <form> and <input>
tags, you're doing it wrong. :-) Maybe you end up with your own PHP
library to do that for you that handles all of the above, but... why,
when there are so many already that do a better job than you can on your
own (because they've had dozens of smart people including security
experts working on them)?

Post by Ashley Sheridan
I would say code forms on your own first, as a learning experience, then
use frameworks once you know what you're doing.

That I'll agree with. "Do it manually for the learning, then use a
battle-hardened tool for real work" is a generally good approach to many
things in programming.

--Larry Garfield

[Paul M Foster]

Post by Larry Garfield

Post by Jim Giner
Never write your own form? I'm guilty - oh, so guilty. What exactly is
a 'security hardened' form?

- All forms need a valid CSRF token to avoid CSRF attacks. This
needs to be matched between the submitted form and server-maintained
state. Do all of your forms have that? Every single one? (A GET
lookup form like a search box doesn't need it, but anything with
POST does, I'd argue.)

Yes. I wrote a "bless" class just for this purpose, which I use on all
form pages.

Post by Larry Garfield
- Do you have a select element? Do you have error handling for when
someone submits a value for that wasn't one of the option elements?

Yes, since I realize that what comes back to me may bear no resemblence
to what I coded in HTML. Thus, I always check for allowed "SELECT"
values.

Post by Larry Garfield
- Your text input field has a max length of 20. Does your code
return an error when the user enters a string of 100 characters?

Yes. Same answer. Putting a max length of 20 in the HTML works okay, but
the user could still submit something much longer if they are attempting
to hack the page. Thus I always check for max characters on the return.

Post by Larry Garfield
- Are you checking for weird edge-case-y character encoding issues?
(Some versions of some browsers can be hacked by sending UTF-7
instead of UTF-8 for certain parts of the request. I don't fully
understand that stuff myself, either.)

No I don't check for this.

Post by Larry Garfield
- You have a "number" field (HTML5). Does your PHP code handle
someone submitting a string anyway?

I don't use HTML5 tags like this, since they are not universally
supported. However, I check that numbers look like numbers on return and
strings look like strings on return. PHP has built-in functions for
this.

All this is part of my validation class.

Post by Larry Garfield
- Are you checking all of those correctly every single time you
write a form?

Except as noted above. This is all home-grown, using native PHP
functions designed to do these things, and classes I've written. I
carefully examine each field when writing the POST-handling code with
the idea in mind that no matter what the HTML says, the return value
must conform to what *I* think it should be. No MVC framework written by
others (though I do conform to MVC paradigm).

Paul

[Larry Garfield]

Post by Paul M Foster

Post by Larry Garfield

Post by Jim Giner
Never write your own form? I'm guilty - oh, so guilty. What exactly is
a 'security hardened' form?

- All forms need a valid CSRF token to avoid CSRF attacks. This
needs to be matched between the submitted form and server-maintained
state. Do all of your forms have that? Every single one? (A GET
lookup form like a search box doesn't need it, but anything with
POST does, I'd argue.)

Yes. I wrote a "bless" class just for this purpose, which I use on all
form pages.

Post by Larry Garfield
- Do you have a select element? Do you have error handling for when
someone submits a value for that wasn't one of the option elements?

Yes, since I realize that what comes back to me may bear no resemblence
to what I coded in HTML. Thus, I always check for allowed "SELECT"
values.

Post by Larry Garfield
- Your text input field has a max length of 20. Does your code
return an error when the user enters a string of 100 characters?

Yes. Same answer. Putting a max length of 20 in the HTML works okay, but
the user could still submit something much longer if they are attempting
to hack the page. Thus I always check for max characters on the return.

Post by Larry Garfield
- Are you checking for weird edge-case-y character encoding issues?
(Some versions of some browsers can be hacked by sending UTF-7
instead of UTF-8 for certain parts of the request. I don't fully
understand that stuff myself, either.)

No I don't check for this.

Post by Larry Garfield
- You have a "number" field (HTML5). Does your PHP code handle
someone submitting a string anyway?

I don't use HTML5 tags like this, since they are not universally
supported. However, I check that numbers look like numbers on return and
strings look like strings on return. PHP has built-in functions for
this.
All this is part of my validation class.

Post by Larry Garfield
- Are you checking all of those correctly every single time you
write a form?

Except as noted above. This is all home-grown, using native PHP
functions designed to do these things, and classes I've written. I
carefully examine each field when writing the POST-handling code with
the idea in mind that no matter what the HTML says, the return value
must conform to what *I* think it should be. No MVC framework written by
others (though I do conform to MVC paradigm).
Paul

Then you're not writing your own form tags from the sound of it; you're
writing your own Form API. Still an improvements. :-)

Now, let's talk about form accessibility...

--Larry Garfield

[Paul M Foster]

[snip]

Post by Larry Garfield

Post by Paul M Foster
Except as noted above. This is all home-grown, using native PHP
functions designed to do these things, and classes I've written. I
carefully examine each field when writing the POST-handling code with
the idea in mind that no matter what the HTML says, the return value
must conform to what *I* think it should be. No MVC framework written by
others (though I do conform to MVC paradigm).
Paul

Then you're not writing your own form tags from the sound of it;
you're writing your own Form API. Still an improvements. :-)

No, I'm writing the form tags as well. I write the whole thing, soup to
nuts. But as I'm writing the back end validation stuff, I realize that
what I wrote in the HTML doesn't matter when it comes to hackers and
script kiddies. So I use my bless and validation libraries to tackle
form responses. That's the point I'm making. I understand what you're
saying about using someone else's framework so you can make sure that
tested code is being used to ensure against hacking attempts. But your
pronouncement was so thunderous that I had to provide the exception. If
you hang around here and read a book or two on security, you can write
your own code that handles this stuff. Particularly if you have an
example like CodeIgniter to use, to see how it's done.

(There are times when I *don't* write the HTML. My wife the designer
does. But I still go in and modify it to provide the validation bits
which she can't do. She uses Dreamweaver, so a lot of the time, she
doesn't even know what the raw HTML looks like.)

Paul

[Larry Garfield]

Post by Paul M Foster
[snip]

Post by Larry Garfield

Post by Paul M Foster
Except as noted above. This is all home-grown, using native PHP
functions designed to do these things, and classes I've written. I
carefully examine each field when writing the POST-handling code with
the idea in mind that no matter what the HTML says, the return value
must conform to what *I* think it should be. No MVC framework written by
others (though I do conform to MVC paradigm).
Paul

Then you're not writing your own form tags from the sound of it;
you're writing your own Form API. Still an improvements. :-)

No, I'm writing the form tags as well. I write the whole thing, soup to
nuts. But as I'm writing the back end validation stuff, I realize that
what I wrote in the HTML doesn't matter when it comes to hackers and
script kiddies. So I use my bless and validation libraries to tackle
form responses. That's the point I'm making. I understand what you're
saying about using someone else's framework so you can make sure that
tested code is being used to ensure against hacking attempts. But your
pronouncement was so thunderous that I had to provide the exception. If
you hang around here and read a book or two on security, you can write
your own code that handles this stuff. Particularly if you have an
example like CodeIgniter to use, to see how it's done.
(There are times when I *don't* write the HTML. My wife the designer
does. But I still go in and modify it to provide the validation bits
which she can't do. She uses Dreamweaver, so a lot of the time, she
doesn't even know what the raw HTML looks like.)
Paul

So you're writing your own form tags for each specific time you need a
form, or you wrote your own form builder API that is writing the form
tags for you?

Because if the former, I claim it's insecure. The development process
is insecure, so you will screw up sooner or later. You're only human.

--Larry Garfield

[Paul M Foster]

On Thu, Aug 01, 2013 at 02:35:04PM -0500, Larry Garfield wrote:

[snip]

Post by Larry Garfield
So you're writing your own form tags for each specific time you need
a form, or you wrote your own form builder API that is writing the
form tags for you?

Unless my wife creates the form in Dreamweaver, I write the HTML for the
form fields. Even when she does, I add the proper code to validate each
field and the form overall, using my field validation class, etc.

Post by Larry Garfield
Because if the former, I claim it's insecure. The development
process is insecure, so you will screw up sooner or later. You're
only human.

A-ha! That's where you're wrong, Matey! For I am SUPER-CODER! Faster
than a speeding 300 baud modem! More powerful than a teletype! Able
to leap tall procedural functions at a single bound! With my pocket
protector and trusty slide rule, I defend the indefensible and champion
the cause of spaghetti code!

So there! ;-P

Paul

[Robert Cummings]

Post by Paul M Foster
[snip]

Post by Larry Garfield
So you're writing your own form tags for each specific time you need
a form, or you wrote your own form builder API that is writing the
form tags for you?

Unless my wife creates the form in Dreamweaver, I write the HTML for the
form fields. Even when she does, I add the proper code to validate each
field and the form overall, using my field validation class, etc.

Post by Larry Garfield
Because if the former, I claim it's insecure. The development
process is insecure, so you will screw up sooner or later. You're
only human.

A-ha! That's where you're wrong, Matey! For I am SUPER-CODER! Faster
than a speeding 300 baud modem! More powerful than a teletype! Able
to leap tall procedural functions at a single bound! With my pocket
protector and trusty slide rule, I defend the indefensible and champion
the cause of spaghetti code!
So there! ;-P

I often get paid to fix such code... keep up the questionable
methodologies ;)

Cheers,
Rob.

[Robert Cummings]

Post by iccsi
<form action="action.php" method="post">
<p>Your name: <input type="text" name="name" /></p>
<p>Your age: <input type="text" name="age" /></p>
<p><input type="submit" /></p>
</form>In the PHP tutorial manual, it says that we can have post action to
the form itself just like above coding.I would like to know in the real
projects, can we have action to the same PHP file, since that we only need
have one filebut not 2 files foe POST request,Your help and information is
great appreciated,regards,Iccsi,

From "my" experience, I would suggest that you ALWAYS post back to the
same URL. All forms I've seen that post to a different target have
issues when validation fails and they suddenly need to go back to the
original form-- they tend to implement weird and not so wonderful
techniques to get back to that form while preserving the posted data in
the session or something. If they try to go back at all... some just say
fail and tell you to hit your browser's back button.

Leaving the action attribute empty should cause the browser to post back
to the same URL without you needing to re-iterate it programmatically in
the action attribute.

Cheers,
Rob.