php-general Digest 29 Jul 2013 16:50:06 -0000 Issue 8313
Topics (messages 321731 through 321739):
Re: POST action
321731 by: Larry Garfield
321732 by: Jim Giner
321733 by: Ashley Sheridan
321734 by: Jim Giner
321735 by: Robert Cummings
321736 by: Robert Cummings
321737 by: Larry Garfield
321738 by: Paul M Foster
321739 by: Larry Garfield
Administrivia:
To subscribe to the digest, e-mail:
php-general-digest-subscr...@lists.php.net
To unsubscribe from the digest, e-mail:
php-general-digest-unsubscr...@lists.php.net
To post to the list, e-mail:
php-gene...@lists.php.net
----------------------------------------------------------------------
--- Begin Message ---
On 07/28/2013 12:14 PM, iccsi wrote:
<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
--- End Message ---
--- Begin Message ---
On 7/28/2013 1:26 PM, Larry Garfield wrote:
On 07/28/2013 12:14 PM, iccsi wrote:
<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
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.
--- End Message ---
--- Begin Message ---
On Sun, 2013-07-28 at 13:37 -0400, Jim Giner wrote:
> On 7/28/2013 1:26 PM, Larry Garfield wrote:
> > On 07/28/2013 12:14 PM, iccsi wrote:
> >> <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
> 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
--- End Message ---
--- Begin Message ---
On 7/28/2013 1:38 PM, Ashley Sheridan wrote:
On Sun, 2013-07-28 at 13:37 -0400, Jim Giner wrote:
On 7/28/2013 1:26 PM, Larry Garfield wrote:
> On 07/28/2013 12:14 PM, iccsi wrote:
>> <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
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?
--- End Message ---
--- Begin Message ---
On 13-07-28 01:14 PM, iccsi wrote:
<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.
--
E-Mail Disclaimer: Information contained in this message and any
attached documents is considered confidential and legally protected.
This message is intended solely for the addressee(s). Disclosure,
copying, and distribution are prohibited unless authorized.
--- End Message ---
--- Begin Message ---
On 13-07-28 01:51 PM, Jim Giner wrote:
On 7/28/2013 1:38 PM, Ashley Sheridan wrote:
On Sun, 2013-07-28 at 13:37 -0400, Jim Giner wrote:
On 7/28/2013 1:26 PM, Larry Garfield wrote:
On 07/28/2013 12:14 PM, iccsi wrote:
<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
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.
--
E-Mail Disclaimer: Information contained in this message and any
attached documents is considered confidential and legally protected.
This message is intended solely for the addressee(s). Disclosure,
copying, and distribution are prohibited unless authorized.
--- End Message ---
--- Begin Message ---
On 07/28/2013 12:38 PM, Ashley Sheridan wrote:
On Sun, 2013-07-28 at 13:37 -0400, Jim Giner wrote:
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)?
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
--- End Message ---
--- Begin Message ---
On Sun, Jul 28, 2013 at 08:46:06PM -0500, Larry Garfield wrote:
> On 07/28/2013 12:38 PM, Ashley Sheridan wrote:
> >On Sun, 2013-07-28 at 13:37 -0400, Jim Giner wrote:
> >
> >>
> >>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.
>
> - 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.
>
> - 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.
>
> - 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.
>
> - 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.
>
> - 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
--
Paul M. Foster
http://noferblatz.com
http://quillandmouse.com
--- End Message ---
--- Begin Message ---
On 7/28/13 9:23 PM, Paul M Foster wrote:
On Sun, Jul 28, 2013 at 08:46:06PM -0500, Larry Garfield wrote:
On 07/28/2013 12:38 PM, Ashley Sheridan wrote:
On Sun, 2013-07-28 at 13:37 -0400, Jim Giner wrote:
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.
- 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.
- 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.
- 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.
- 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.
- 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
--- End Message ---
