Re: [PHP] POST action
On 7/29/13 3:02 PM, Paul M Foster wrote: On Mon, Jul 29, 2013 at 11:50:01AM -0500, Larry Garfield wrote: On 7/28/13 9:23 PM, Paul M Foster wrote: On Sun, Jul 28, 2013 at 08:46:06PM -0500, Larry Garfield wrote: [snip] 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 -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] POST action
On Thu, Aug 01, 2013 at 02:35:04PM -0500, Larry Garfield wrote: [snip] 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. 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 -- Paul M. Foster http://noferblatz.com http://quillandmouse.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] POST action
On 13-08-01 05:14 PM, Paul M Foster wrote: On Thu, Aug 01, 2013 at 02:35:04PM -0500, Larry Garfield wrote: [snip] 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. 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. -- 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. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] POST action
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 -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] POST action
On Mon, Jul 29, 2013 at 11:50:01AM -0500, Larry Garfield wrote: On 7/28/13 9:23 PM, Paul M Foster wrote: On Sun, Jul 28, 2013 at 08:46:06PM -0500, Larry Garfield wrote: [snip] 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 -- Paul M. Foster http://noferblatz.com http://quillandmouse.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] POST action
On 07/28/2013 12:14 PM, iccsi wrote: form action=action.php method=post pYour name: input type=text name=name //p pYour age: input type=text name=age //p pinput type=submit //p /formIn 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 -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] POST action
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 pYour name: input type=text name=name //p pYour age: input type=text name=age //p pinput type=submit //p /formIn 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. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] POST action
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 pYour name: input type=text name=name //p pYour age: input type=text name=age //p pinput type=submit //p /formIn 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
Re: [PHP] POST action
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 pYour name: input type=text name=name //p pYour age: input type=text name=age //p pinput type=submit //p /formIn 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?
Re: [PHP] POST action
On 13-07-28 01:14 PM, iccsi wrote: form action=action.php method=post pYour name: input type=text name=name //p pYour age: input type=text name=age //p pinput type=submit //p /formIn 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. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] POST action
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 pYour name: input type=text name=name //p pYour age: input type=text name=age //p pinput type=submit //p /formIn 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. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] POST action
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 -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] POST action
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 -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
